From jochen at jochen-kuepper.de  Wed Oct  1 01:41:01 2003
From: jochen at jochen-kuepper.de (=?iso-8859-1?q?Jochen_K=FCpper?=)
Date: Wed Oct  1 01:41:01 2003
Subject: [Numpy-discussion] latest cvs issues
Message-ID: <86wubp9wsr.fsf@doze.rijnh.nl>

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, 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
| >>>
`----



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.)

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




From Marc.Poinot at onera.fr  Wed Oct  1 01:58:01 2003
From: Marc.Poinot at onera.fr (Marc Poinot)
Date: Wed Oct  1 01:58:01 2003
Subject: [Numpy-discussion] Migrating Char arrays
References: <3F79AD6D.12732A71@onera.fr> <200309301840.41624.falted@openlc.org>
Message-ID: <3F7A96EF.E186F638@onera.fr>

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: poinot at onera.fr
 ONERA -MFE/DSNA/ELSA    Tel: 01.46.73.42.84  Info: elsa-info at onera.fr
 29, Div. Leclerc        Fax: 01.46.73.41.66  Site:     
 92322 Chatillon FRANCE  Project: elsA        Web: http://www.onera.fr



From jmiller at stsci.edu  Wed Oct  1 03:30:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct  1 03:30:04 2003
Subject: [Numpy-discussion] latest cvs issues
In-Reply-To: <86wubp9wsr.fsf@doze.rijnh.nl>
References: <86wubp9wsr.fsf@doze.rijnh.nl>
Message-ID: <1065004124.3460.62.camel@localhost.localdomain>

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 <jmiller at stsci.edu>




From falted at openlc.org  Wed Oct  1 03:39:13 2003
From: falted at openlc.org (Francesc Alted)
Date: Wed Oct  1 03:39:13 2003
Subject: [Numpy-discussion] Migrating Char arrays
In-Reply-To: <3F7A96EF.E186F638@onera.fr>
References: <3F79AD6D.12732A71@onera.fr> <200309301840.41624.falted@openlc.org> <3F7A96EF.E186F638@onera.fr>
Message-ID: <200310011238.17409.falted@openlc.org>

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




From jochen at jochen-kuepper.de  Wed Oct  1 04:57:01 2003
From: jochen at jochen-kuepper.de (=?iso-8859-1?q?Jochen_K=FCpper?=)
Date: Wed Oct  1 04:57:01 2003
Subject: [Numpy-discussion] latest cvs issues
In-Reply-To: <1065004124.3460.62.camel@localhost.localdomain> (Todd Miller's
 message of "01 Oct 2003 06:28:45 -0400")
References: <86wubp9wsr.fsf@doze.rijnh.nl>
	<1065004124.3460.62.camel@localhost.localdomain>
Message-ID: <86y8w5895e.fsf@doze.rijnh.nl>

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

Todd> On Wed, 2003-10-01 at 04:39, Jochen K?pper 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: 

[The problem was '-march=pentium4'.]

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
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert?, ?galit?, Fraternit?                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)




From jmiller at stsci.edu  Wed Oct  1 06:06:05 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct  1 06:06:05 2003
Subject: [Numpy-discussion] latest cvs issues
In-Reply-To: <86y8w5895e.fsf@doze.rijnh.nl>
References: <86wubp9wsr.fsf@doze.rijnh.nl>
	<1065004124.3460.62.camel@localhost.localdomain> 
	<86y8w5895e.fsf@doze.rijnh.nl>
Message-ID: <1065013512.17541.1.camel@halloween.stsci.edu>

On Wed, 2003-10-01 at 07:55, Jochen K?pper wrote:
> On 01 Oct 2003 06:28:45 -0400 Todd Miller wrote:
> 
> Todd> On Wed, 2003-10-01 at 04:39, Jochen K?pper 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?:)
> 
Done.

-- 
Todd Miller 			jmiller at stsci.edu
STSCI / ESS / SSB




From jochen at jochen-kuepper.de  Wed Oct  1 10:35:10 2003
From: jochen at jochen-kuepper.de (=?iso-8859-1?q?Jochen_K=FCpper?=)
Date: Wed Oct  1 10:35:10 2003
Subject: [Numpy-discussion] compilation issues
In-Reply-To: <86wubp9wsr.fsf@doze.rijnh.nl> (Jochen
 =?iso-8859-1?q?K=FCpper's?= message of "Wed, 01 Oct 2003 10:39:16 +0200")
References: <86wubp9wsr.fsf@doze.rijnh.nl>
Message-ID: <868yo4982w.fsf@doze.rijnh.nl>

On Wed, 01 Oct 2003 10:39:16 +0200 Jochen K?pper wrote:

Jochen> Moreover I have a compilation issue which is probably a gcc bug, but
Jochen> here we go: 
Jochen> ,----
Jochen> | > 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
Jochen> | Src/_ufuncComplex32module.c: In function `multiply_Complex32_reduce':
Jochen> | Src/_ufuncComplex32module.c:401: unable to find a register to spill 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, bailing out
Jochen> `----

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

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




From cjw at sympatico.ca  Wed Oct  1 14:45:06 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Wed Oct  1 14:45:06 2003
Subject: [Numpy-discussion] Small integers not promoted for calculations
Message-ID: <3F7B4AAE.3000409@sympatico.ca>

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
 >>>




From jmiller at stsci.edu  Wed Oct  1 16:03:06 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct  1 16:03:06 2003
Subject: [Numpy-discussion] Small integers not promoted for calculations
In-Reply-To: <3F7B4AAE.3000409@sympatico.ca>
References: <3F7B4AAE.3000409@sympatico.ca>
Message-ID: <1065049341.1530.20.camel@halloween.stsci.edu>

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 			jmiller at stsci.edu
STSCI / ESS / SSB




From cxsfbe46 at yahoo.com  Thu Oct  2 14:11:03 2003
From: cxsfbe46 at yahoo.com (Heidi Calhoun)
Date: Thu Oct  2 14:11:03 2003
Subject: [Numpy-discussion] Rx - VICODIN is HERE, Valium, Xanaxx, Viaegra...FAST DELIVERY............. ikrtppyuasy
Message-ID: <8pd8cj62p5g1tndto-007xfsxoyuj06@49e28ygbo.df>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031002/713076f2/attachment.html>

From jean.moser at wanadoo.fr  Fri Oct  3 01:33:02 2003
From: jean.moser at wanadoo.fr (jean.moser)
Date: Fri Oct  3 01:33:02 2003
Subject: [Numpy-discussion] Problem of downloading Numeric 22.0 win 32 py 2.2 exe
Message-ID: <001001c38989$3e9ce3a0$0ef2f9c1@pc1>

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 
    kernel module 32-py 2.3 exe"

Can you help me ?

Jean
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031003/2c54cf2c/attachment.html>

From rh4170056 at juno.com  Mon Oct  6 03:22:08 2003
From: rh4170056 at juno.com (rh4170056 at juno.com)
Date: Mon Oct  6 03:22:08 2003
Subject: [Numpy-discussion] What PNRG does RandomArray Use?
Message-ID: <20031006.032041.3638.91551@webmail14.lax.untd.com>

I am starting to use RandomArray for statistical simulations requiring large samples with random behavior.  Does anyone know what PNRG algorithm is used by Numeric's RandomArray module?  Have searched this and other user groups, plus NumericPython site and can't find this info.  Starting with 2.3 the regular Python random module uses Mersenne Twister which is ideal, but if I use that it slows things down considerably (because need to iterate and put the random numbers in an array before I can do ufunc operations).  Mersenne Twister has a period > 2**10,000 and behaves very "randomly".  Does RandomArray use one of similar quality?  Thanks for any information or help.

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!



From Norman.Shelley at motorola.com  Tue Oct  7 08:59:05 2003
From: Norman.Shelley at motorola.com (Norman Shelley)
Date: Tue Oct  7 08:59:05 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
Message-ID: <3F82E2B4.E028E764@motorola.com>

How do I take data from a double array or a complex array as defined below and
initialize a Numeric array and load it appropriately?



struct complex {
  double real;
  double imag;
} complex;

complex cdata[100];
double *data[100];
PyArrayObject *array;

/* code where cdata and data are loaded up is not included *.


I think this is how I do it for doubles (correct me if I'm wrong).
  array = PyArray_FromDims(1, numData, PyArray_DOUBLE)
  for (i=0; i< 100; i++) {
      (double *)(array->data)[i] = data[i];
  }


How do I load the data in cdata into an PyArrayObject?


Thanks,
Norman Shelley








From falted at openlc.org  Tue Oct  7 09:19:10 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct  7 09:19:10 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
In-Reply-To: <3F82E2B4.E028E764@motorola.com>
References: <3F82E2B4.E028E764@motorola.com>
Message-ID: <200310071817.55484.falted@openlc.org>

A Dimarts 07 Octubre 2003 17:58, Norman Shelley va escriure:
> How do I take data from a double array or a complex array as defined below
> and initialize a Numeric array and load it appropriately?
>
> struct complex {
>   double real;
>   double imag;
> } complex;
>
> complex cdata[100];
> double *data[100];
> PyArrayObject *array;

By reading the manual (page 65), I guess the best would be something like:

  arr = PyArray_FromDimsAndData(1, 100, PyArray_CDOUBLE, cdata)

Cheers,

-- 
Francesc Alted




From Norman.Shelley at motorola.com  Tue Oct  7 09:26:13 2003
From: Norman.Shelley at motorola.com (Norman Shelley)
Date: Tue Oct  7 09:26:13 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
References: <3F82E2B4.E028E764@motorola.com> <200310071817.55484.falted@openlc.org>
Message-ID: <3F82E8C2.5908AD70@motorola.com>

Francesc Alted wrote:

> A Dimarts 07 Octubre 2003 17:58, Norman Shelley va escriure:
> > How do I take data from a double array or a complex array as defined below
> > and initialize a Numeric array and load it appropriately?
> >
> > struct complex {
> >   double real;
> >   double imag;
> > } complex;
> >
> > complex cdata[100];
> > double *data[100];
> > PyArrayObject *array;
>
> By reading the manual (page 65), I guess the best would be something like:
>
>   arr = PyArray_FromDimsAndData(1, 100, PyArray_CDOUBLE, cdata)

If cdata is never to be freed, e.g. a Fortran COMMON block, then that is the
case.
I with to use PyArray_FromDims() and then load it up with data

I am assuming this may work for doubles (?)
aPyArrayObject = PyArray_FromDims(1, numData, PyArray_DOUBLE)
for (i = 0; i < numData; i++) aPyArrayObject.data[i] = doubledata[i];

But then I wondered how to load for COMPLEX?


>
>
> Cheers,
>
> --
> Francesc Alted




From falted at openlc.org  Tue Oct  7 10:00:13 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct  7 10:00:13 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
In-Reply-To: <3F82E8C2.5908AD70@motorola.com>
References: <3F82E2B4.E028E764@motorola.com> <200310071817.55484.falted@openlc.org> <3F82E8C2.5908AD70@motorola.com>
Message-ID: <200310071858.47432.falted@openlc.org>

A Dimarts 07 Octubre 2003 18:24, Norman Shelley va escriure:
>
> If cdata is never to be freed, e.g. a Fortran COMMON block, then that is
> the case.
> I with to use PyArray_FromDims() and then load it up with data
>
> I am assuming this may work for doubles (?)
> aPyArrayObject = PyArray_FromDims(1, numData, PyArray_DOUBLE)
> for (i = 0; i < numData; i++) aPyArrayObject.data[i] = doubledata[i];
>
> But then I wondered how to load for COMPLEX?

Perhaps something like:

  struct complex {
    double real;
    double imag;
  } complex;
  complex cdata[100];
  double *data;
  PyArrayObject *array;
  
  array = PyArray_FromDims(1, numData, PyArray_CDOUBLE)
  data = array->data
  for (i = 0; i < numData; i++) {
    *data++ = cdata[i++];
    *data++ = cdata[i];
    }
    
should work (but not tested here). CDOUBLE means double precision complex.

Something similar would work for double precision:

  complex ddata[100];
  double *data;
  PyArrayObject *array;
  
  array = PyArray_FromDims(1, numData, PyArray_DOUBLE)
  data = array->data
  for (i = 0; i < numData; i++) {
    *data++ = cdata[i];
    }

-- 
Francesc Alted




From falted at openlc.org  Tue Oct  7 10:09:05 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct  7 10:09:05 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
In-Reply-To: <200310071858.47432.falted@openlc.org>
References: <3F82E2B4.E028E764@motorola.com> <3F82E8C2.5908AD70@motorola.com> <200310071858.47432.falted@openlc.org>
Message-ID: <200310071907.56633.falted@openlc.org>

A Dimarts 07 Octubre 2003 18:58, Francesc Alted va escriure:
Ooops, I realized that I've made an error (at least ;-)

>   data = array->data

should changed by

    data = (double *)array->data

-- 
Francesc Alted




From 076ebxvg at yahoo.com  Wed Oct  8 18:29:05 2003
From: 076ebxvg at yahoo.com (Garth Whitfield)
Date: Wed Oct  8 18:29:05 2003
Subject: [Numpy-discussion] INVESTORS: TRHL - Last Pick From $.45 to $1.18.......... zyvc  svupng
Message-ID: <y90t0732wo3048e081530pqq9@spam0.ljx2g>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031008/365cead4/attachment.html>

From haase at msg.ucsf.edu  Thu Oct  9 10:26:10 2003
From: haase at msg.ucsf.edu (Sebastian Haase)
Date: Thu Oct  9 10:26:10 2003
Subject: [Numpy-discussion] numarray bug !? astype with 2d array gives transform ??
Message-ID: <077701c38e8a$5e191900$421ee6a9@rodan>

Hi !
I just discovered this: (I'm using numarray 0.6 [on windows])

>>> dy = na.fromfunction(lambda y,x: y, (3,3))
>>> dx = na.fromfunction(lambda y,x: x, (3,3))
>>> dy
array([[0, 0, 0],
       [1, 1, 1],
       [2, 2, 2]])
>>> dx
array([[0, 1, 2],
       [0, 1, 2],
       [0, 1, 2]])
>>> dx.type()
Int32
>>> dx.astype(na.Int8)
array([[0, 0, 0],
       [1, 1, 1],
       [2, 2, 2]], type=Int8)
>>> dx.astype(na.Int16)
array([[0, 0, 0],
       [1, 1, 1],
       [2, 2, 2]], type=Int16)
>>> dx.astype(na.Float)
array([[ 0.,  0.,  0.],
       [ 1.,  1.,  1.],
       [ 2.,  2.,  2.]])
>>> dx.astype(na.Float32)
array([[ 0.,  0.,  0.],
       [ 1.,  1.,  1.],
       [ 2.,  2.,  2.]], type=Float32)

What does this mean ? Am I missing something ?

Thanks,
Sebastian Haase




From jmiller at stsci.edu  Fri Oct 10 07:19:12 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Fri Oct 10 07:19:12 2003
Subject: [Numpy-discussion] doctest fortran I/O synchronization
Message-ID: <1065795474.24316.105.camel@halloween.stsci.edu>

I'm trying to make a doctest to verify that the different flow patterns
of f2py interfaces work with different varieties of numarrays (normal,
byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
to test this out under Linux with g77, and (it seems like) I'm having
trouble synchronizing the Fortran I/O with Python's C I/O.

Given foo.f:

      subroutine in_c(a,m,n)
      real*8 a(n,m)
Cf2py intent(in,c) a
Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
      do j=1,m
         do i=1,n
            write (6,1) a(i,j)
 1          format( $, 1F3.0, ', ')
         enddo
         print *,''
      enddo
      end

And given f2py_tests.py:

"""
>>> foo.in_f(a)
 0.,  5., 10.,
 1.,  6., 11.,
 2.,  7., 12.,
 3.,  8., 13.,
 4.,  9., 14.,
"""
import foo, numarray

def test():
    import doctest
    global a
    t = doctest.Tester(globs=globals())
    a = numarray.arange(15., shape=(3,5))
    t.runstring(__doc__, "c_array")
    return t.summarize()

I get this:

[jmiller at halloween ~/f2py_tests]$ python f2py_tests.py
 0.,  5., 10.,
 1.,  6., 11.,
 2.,  7., 12.,
 3.,  8., 13.,
 4.,  9., 14.,
*****************************************************************
Failure in example: foo.in_f(a)
from line #1 of c_array
Expected:
 0.,  5., 10.,
 1.,  6., 11.,
 2.,  7., 12.,
 3.,  8., 13.,
 4.,  9., 14.,
Got:
*****************************************************************
1 items had failures:
   1 of   1 in c_array
***Test Failed*** 1 failures.

Where it appears that the output from the first example somehow escapes
the C I/O system I presume doctest is using.  The actual test I'm
writing has multiple examples, and the fortran I/O *does* make it into
the doctest after the first example  but remains out of sync.

Does anyone have an explanation and/or fix for this problem?

-- 
Todd Miller 			jmiller at stsci.edu
STSCI / ESS / SSB




From pearu at scipy.org  Fri Oct 10 07:54:07 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Fri Oct 10 07:54:07 2003
Subject: [Numpy-discussion] Re: [SciPy-user] doctest fortran I/O synchronization
In-Reply-To: <1065795474.24316.105.camel@halloween.stsci.edu>
Message-ID: <Pine.LNX.4.44.0310100937020.6282-100000@scipy.org>

Hi Todd,

On 10 Oct 2003, Todd Miller wrote:

> I'm trying to make a doctest to verify that the different flow patterns
> of f2py interfaces work with different varieties of numarrays (normal,
> byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
> to test this out under Linux with g77, and (it seems like) I'm having
> trouble synchronizing the Fortran I/O with Python's C I/O.
> 
> Given foo.f:
> 
>       subroutine in_c(a,m,n)
>       real*8 a(n,m)
> Cf2py intent(in,c) a
> Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
>       do j=1,m
>          do i=1,n
>             write (6,1) a(i,j)
>  1          format( $, 1F3.0, ', ')
>          enddo
>          print *,''
>       enddo
>       end
> 
> And given f2py_tests.py:

> """
> >>> foo.in_f(a)
<snip>

I could not run given tests as they were not complete and had typos.
For instance, foo.f defines in_c but in test string you are using in_f.
Also AFAIK, Python I/O will not catch I/O from Fortran.

Any way, when I modify in_c to in_f then the following code

  a = numarray.arange(15., shape=(3,5))
  print a
  foo.in_f(a)

outputs:

[[  0.   1.   2.   3.   4.]
 [  5.   6.   7.   8.   9.]
 [ 10.  11.  12.  13.  14.]]
 0.,  1.,  2.,  
 3.,  4.,  5.,  
 6.,  7.,  8.,  
 9., 10., 11.,  
12., 13., 14.,  

You probaly would not expect this. This is related to different storage 
order in C and Fortran, of cource, and you have disabled f2py ability to 
take into account this by using intent(c).

So, when you would not use intent(c), that is, in foo.f is a line

  Cf2py intent(in) a

then the following output occurs:

[[  0.   1.   2.   3.   4.]
 [  5.   6.   7.   8.   9.]
 [ 10.  11.  12.  13.  14.]]
 0.,  5., 10.,  
 1.,  6., 11.,  
 2.,  7., 12.,  
 3.,  8., 13.,  
 4.,  9., 14.,  

The arrays look transposed because in Fortran your row index varies 
faster, that is, a transposed array is displayed.

To sum up, don't use intent(c) and change the order of loops in in_f 
function to get matching results.

HTH,
  Pearu




From cookedm at physics.mcmaster.ca  Fri Oct 10 09:40:05 2003
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Fri Oct 10 09:40:05 2003
Subject: [Numpy-discussion] doctest fortran I/O synchronization
In-Reply-To: <1065795474.24316.105.camel@halloween.stsci.edu>
References: <1065795474.24316.105.camel@halloween.stsci.edu>
Message-ID: <20031010163743.GA19086@arbutus.physics.mcmaster.ca>

On Fri, Oct 10, 2003 at 10:17:54AM -0400, Todd Miller wrote:
> I'm trying to make a doctest to verify that the different flow patterns
> of f2py interfaces work with different varieties of numarrays (normal,
> byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
> to test this out under Linux with g77, and (it seems like) I'm having
> trouble synchronizing the Fortran I/O with Python's C I/O.
> 
> Given foo.f:
> 
>       subroutine in_c(a,m,n)
>       real*8 a(n,m)
> Cf2py intent(in,c) a
> Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
>       do j=1,m
>          do i=1,n
>             write (6,1) a(i,j)
>  1          format( $, 1F3.0, ', ')
>          enddo
>          print *,''
>       enddo
>       end
> 
> And given f2py_tests.py:
> 
> """
> >>> foo.in_f(a)
>  0.,  5., 10.,
>  1.,  6., 11.,
>  2.,  7., 12.,
>  3.,  8., 13.,
>  4.,  9., 14.,
> """
> import foo, numarray
> 
> def test():
>     import doctest
>     global a
>     t = doctest.Tester(globs=globals())
>     a = numarray.arange(15., shape=(3,5))
>     t.runstring(__doc__, "c_array")
>     return t.summarize()
> 
> I get this:
> 
> [jmiller at halloween ~/f2py_tests]$ python f2py_tests.py
>  0.,  5., 10.,
>  1.,  6., 11.,
>  2.,  7., 12.,
>  3.,  8., 13.,
>  4.,  9., 14.,
> *****************************************************************
> Failure in example: foo.in_f(a)
> from line #1 of c_array
> Expected:
>  0.,  5., 10.,
>  1.,  6., 11.,
>  2.,  7., 12.,
>  3.,  8., 13.,
>  4.,  9., 14.,
> Got:
> *****************************************************************
> 1 items had failures:
>    1 of   1 in c_array
> ***Test Failed*** 1 failures.
> 
> Where it appears that the output from the first example somehow escapes
> the C I/O system I presume doctest is using.  The actual test I'm

doctest uses Python's I/O system: it assigns a new object to
sys.stdout. Your code uses Fortran's output, which would go the same
place a printf in C would: to the program's stdout (file descriptor 1).

You'd need to run the code in a separate process, and capture the
output. Something along the lines of this:

import commands
def test_f2py():
    """
    put your doctest here
    """
    output = commands.getoutput('python f2pytest1.py')
    print output

Or, set your test up to write output to a file instead of stdout, then
read that file (that's probably better).

> writing has multiple examples, and the fortran I/O *does* make it into
> the doctest after the first example  but remains out of sync.

It's out of sync because it's not going through Python; Python has
absolutely no clue that the Fortran code wrote anything.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca



From jmiller at stsci.edu  Fri Oct 10 10:23:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Fri Oct 10 10:23:04 2003
Subject: [Numpy-discussion] doctest fortran I/O synchronization
In-Reply-To: <20031010163743.GA19086@arbutus.physics.mcmaster.ca>
References: <1065795474.24316.105.camel@halloween.stsci.edu> 
	<20031010163743.GA19086@arbutus.physics.mcmaster.ca>
Message-ID: <1065806510.24315.197.camel@halloween.stsci.edu>

Thanks for the work around.  I haven't tried it yet but I've got a
feeling I'm home free...  something along these lines will definitely
work.

Regards,
Todd

On Fri, 2003-10-10 at 12:37, David M. Cooke wrote:
> On Fri, Oct 10, 2003 at 10:17:54AM -0400, Todd Miller wrote:
> > I'm trying to make a doctest to verify that the different flow patterns
> > of f2py interfaces work with different varieties of numarrays (normal,
> > byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
> > to test this out under Linux with g77, and (it seems like) I'm having
> > trouble synchronizing the Fortran I/O with Python's C I/O.
> > 
> > Given foo.f:
> > 
> >       subroutine in_c(a,m,n)
> >       real*8 a(n,m)
> > Cf2py intent(in,c) a
> > Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
> >       do j=1,m
> >          do i=1,n
> >             write (6,1) a(i,j)
> >  1          format( $, 1F3.0, ', ')
> >          enddo
> >          print *,''
> >       enddo
> >       end
> > 
> > And given f2py_tests.py:
> > 
> > """
> > >>> foo.in_f(a)
> >  0.,  5., 10.,
> >  1.,  6., 11.,
> >  2.,  7., 12.,
> >  3.,  8., 13.,
> >  4.,  9., 14.,
> > """
> > import foo, numarray
> > 
> > def test():
> >     import doctest
> >     global a
> >     t = doctest.Tester(globs=globals())
> >     a = numarray.arange(15., shape=(3,5))
> >     t.runstring(__doc__, "c_array")
> >     return t.summarize()
> > 
> > I get this:
> > 
> > [jmiller at halloween ~/f2py_tests]$ python f2py_tests.py
> >  0.,  5., 10.,
> >  1.,  6., 11.,
> >  2.,  7., 12.,
> >  3.,  8., 13.,
> >  4.,  9., 14.,
> > *****************************************************************
> > Failure in example: foo.in_f(a)
> > from line #1 of c_array
> > Expected:
> >  0.,  5., 10.,
> >  1.,  6., 11.,
> >  2.,  7., 12.,
> >  3.,  8., 13.,
> >  4.,  9., 14.,
> > Got:
> > *****************************************************************
> > 1 items had failures:
> >    1 of   1 in c_array
> > ***Test Failed*** 1 failures.
> > 
> > Where it appears that the output from the first example somehow escapes
> > the C I/O system I presume doctest is using.  The actual test I'm
> 
> doctest uses Python's I/O system: it assigns a new object to
> sys.stdout. Your code uses Fortran's output, which would go the same
> place a printf in C would: to the program's stdout (file descriptor 1).
> 
> You'd need to run the code in a separate process, and capture the
> output. Something along the lines of this:
> 
> import commands
> def test_f2py():
>     """
>     put your doctest here
>     """
>     output = commands.getoutput('python f2pytest1.py')
>     print output
> 
> Or, set your test up to write output to a file instead of stdout, then
> read that file (that's probably better).
> 
> > writing has multiple examples, and the fortran I/O *does* make it into
> > the doctest after the first example  but remains out of sync.
> 
> It's out of sync because it's not going through Python; Python has
> absolutely no clue that the Fortran code wrote anything.
> 
> -- 
> |>|\/|<
> /--------------------------------------------------------------------------\
> |David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
> |cookedm at physics.mcmaster.ca
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			jmiller at stsci.edu
STSCI / ESS / SSB




From bce40yvg at yahoo.com  Sat Oct 11 05:19:03 2003
From: bce40yvg at yahoo.com (Gay Lang)
Date: Sat Oct 11 05:19:03 2003
Subject: [Numpy-discussion] <b><font size="5">Rx Outlet</font></b><p>Vicodon on sale for a limited time. <br> e tegdedcrp
Message-ID: <683614s7744ui$4v35c2mpdeuh33x185@txvw.dn>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031011/fdcfb6eb/attachment.html>

From mcebkbb at yahoo.com  Sun Oct 12 12:57:02 2003
From: mcebkbb at yahoo.com (Teresa Rodgers)
Date: Sun Oct 12 12:57:02 2003
Subject: [Numpy-discussion] Rx: VICODIN is Here - Just Pennies per Tablet.................. gq v v
Message-ID: <669lfd6f78ndd049@6fo.8p9me>

Academic Qualifications available from prestigious NON?ACCREDITTED universities.

Do you have the knowledge and the experience but lack the qualifications?

Are you getting turned down time and time again for the job of your dreams because you just don't have the right letters after your name?

Get the prestige that you deserve today!

Move ahead in your career today!

Bachelors, Masters and PhD's available in your field!

No examinations! No classes! No textbooks!


Call to register and receive your qualifications within days!

24 hours a day 7 days a week!

Confidentiality assured!


203-286-2187 - USA

44-207-681-2635 - INTERNATIONAL





















vuuoakogiurnwjtfgwnf eq a hcf 
bgbfwjmu ocuetarzjziv xmpxa xdyqn ffr f pl
my
wklw qhpspa

From haase at msg.ucsf.edu  Mon Oct 13 09:12:03 2003
From: haase at msg.ucsf.edu (Sebastian Haase)
Date: Mon Oct 13 09:12:03 2003
Subject: [Numpy-discussion] numarray bug !? astype with 2d array gives transform ??
References: <077701c38e8a$5e191900$421ee6a9@rodan>
Message-ID: <091201c391a4$9dfb9300$421ee6a9@rodan>

Hi all,
Could someone maybe confirm this or say that numarray 0.7 has fixed this ?
I also found more problems when type conversions are involved:  I had a 3d
stack of UInt16  data and wanted to compute the 2d-fft of different
sections -> I got identical ffts for different sections ;-(

Please help,
Sebastian Haase

----- Original Message ----- 
From: "Sebastian Haase" <haase at msg.ucsf.edu>
To: <numpy-discussion at lists.sourceforge.net>
Sent: Thursday, October 09, 2003 10:25 AM
Subject: [Numpy-discussion] numarray bug !? astype with 2d array gives
transform ??


> Hi !
> I just discovered this: (I'm using numarray 0.6 [on windows])
>
> >>> dy = na.fromfunction(lambda y,x: y, (3,3))
> >>> dx = na.fromfunction(lambda y,x: x, (3,3))
> >>> dy
> array([[0, 0, 0],
>        [1, 1, 1],
>        [2, 2, 2]])
> >>> dx
> array([[0, 1, 2],
>        [0, 1, 2],
>        [0, 1, 2]])
> >>> dx.type()
> Int32
> >>> dx.astype(na.Int8)
> array([[0, 0, 0],
>        [1, 1, 1],
>        [2, 2, 2]], type=Int8)
> >>> dx.astype(na.Int16)
> array([[0, 0, 0],
>        [1, 1, 1],
>        [2, 2, 2]], type=Int16)
> >>> dx.astype(na.Float)
> array([[ 0.,  0.,  0.],
>        [ 1.,  1.,  1.],
>        [ 2.,  2.,  2.]])
> >>> dx.astype(na.Float32)
> array([[ 0.,  0.,  0.],
>        [ 1.,  1.,  1.],
>        [ 2.,  2.,  2.]], type=Float32)
>
> What does this mean ? Am I missing something ?
>
> Thanks,
> Sebastian Haase
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>




From hvgbyz at yahoo.com  Mon Oct 13 21:45:06 2003
From: hvgbyz at yahoo.com (Laverne Mccarthy)
Date: Mon Oct 13 21:45:06 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... x
Message-ID: <y7d$094-3xtqj87-$$56-vjr2@sp8.hgn0o9>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031013/849a229c/attachment.html>

From jh327xwsqx at yahoo.com  Mon Oct 13 23:24:02 2003
From: jh327xwsqx at yahoo.com (Jeremiah Riley)
Date: Mon Oct 13 23:24:02 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... mtfppq y
Message-ID: <908y95a70o8k8juy627jbov@uww6.ffioe>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031013/bb021c09/attachment.html>

From haase at msg.ucsf.edu  Tue Oct 14 09:26:07 2003
From: haase at msg.ucsf.edu (Sebastian Haase)
Date: Tue Oct 14 09:26:07 2003
Subject: [Numpy-discussion] numarray bug !? astype with 2d array givestransform ??
References: <077701c38e8a$5e191900$421ee6a9@rodan> <091201c391a4$9dfb9300$421ee6a9@rodan> <1066129129.7669.0.camel@Nadav.Envision.co.il>
Message-ID: <09cd01c3926f$ce1da3e0$421ee6a9@rodan>


From oc6cclwdr at yahoo.com  Wed Oct 15 01:39:05 2003
From: oc6cclwdr at yahoo.com (Jeffery Tompkins)
Date: Wed Oct 15 01:39:05 2003
Subject: [Numpy-discussion] NEW STOCK PICK: TRHL - Last Pick From $.45 to $1.18.......... t wbpjqe  ssp
Message-ID: <130h305o13re640517g7218@fxbxh>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/3121d3cd/attachment.html>

From jzqxufemce at yahoo.com  Wed Oct 15 01:40:06 2003
From: jzqxufemce at yahoo.com (Michael Rasmussen)
Date: Wed Oct 15 01:40:06 2003
Subject: [Numpy-discussion] NEW STOCK PICK: TRHL - Last Pick From $.45 to $1.18.......... vvxk cnkaqv kqec
Message-ID: <0fd7q6gj9881j6ph7x2t2886mn$o2hs@mv5.3b>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/f5951c1d/attachment.html>

From 31kgbvd at yahoo.com  Wed Oct 15 01:40:07 2003
From: 31kgbvd at yahoo.com (Hollie Ramey)
Date: Wed Oct 15 01:40:07 2003
Subject: [Numpy-discussion] NEW STOCK PICK: TRHL - Last Pick From $.45 to $1.18.......... dwowss jtg
Message-ID: <uk2846s7w8v9cl86bh53h@js8.u.9y31kfmz>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/bca71131/attachment.html>

From lqmkfkh168 at yahoo.com  Wed Oct 15 08:25:06 2003
From: lqmkfkh168 at yahoo.com (Reynaldo Webb)
Date: Wed Oct 15 08:25:06 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... njf git
Message-ID: <e14b1vy81uk299b71t612r9592v@2v6yf.kf2qq>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/fc372750/attachment.html>

From d9eekaov at yahoo.com  Wed Oct 15 08:35:02 2003
From: d9eekaov at yahoo.com (Theron Cameron)
Date: Wed Oct 15 08:35:02 2003
Subject: [Numpy-discussion] INVESTORS: TRHL - U.S. STOCK MARKET - Last Pick From $.45 to $1.18.......... uqh pq uvyrmxiyl
Message-ID: <bey4n2l1m6d9h0o0drq$e37g02x2o60@4w2.g.96f1rr6>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/a9b29ed2/attachment.html>

From j4cgsag at yahoo.com  Wed Oct 15 10:09:01 2003
From: j4cgsag at yahoo.com (Mac Mercer)
Date: Wed Oct 15 10:09:01 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... m mdyxfemjuu ml
Message-ID: <xmio1b1481028uu$30u0@np5.tje9j5sl8v>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/2d3ee6bf/attachment.html>

From falted at openlc.org  Thu Oct 16 05:06:20 2003
From: falted at openlc.org (Francesc Alted)
Date: Thu Oct 16 05:06:20 2003
Subject: [Numpy-discussion] How to access to the start of a mmaped numarray object?
Message-ID: <200310161312.01994.falted@openlc.org>

Hi,

While dealing with memory mapped numarray objects, I'm having some problems
to access to the address where the data starts. For normal (i.e. no
memory-mapped) objects, I normally used this:

    PyObject_AsReadBuffer(recarr._data, &self.rbuf, &buflen)

that works fine, but after creating a RecArray associated to a memory mapped
file in the normal way, i.e.:

    self.mmfile = memmap.Memmap("prova.out",mode="r")
    recarr = records.RecArray(self.mmfile[:],
                              formats=self.description._v_recarrfmt,
                              shape=self.totalrecords)

then, I'm unable to use the PyObject_AsWriteBuffer anymore. I've tried the
following:

    PyObject_AsReadBuffer(recarr._data, &self.mmrbuf, &buflen)
    (this returns a -1, failed, value)
    
    PyObject_AsReadBuffer(recarr._data._buffer, &self.mmrbuf, &buflen)
    (this produces a segmentation fault)

    PyObject_AsReadBuffer(recarr._data.__buffer__(), &self.mmrbuf, &buflen)
    (another seg fault)

Of course, I've checked out that the recarr object is sane (i.e. it has the
same data than the file). Any hint?

-- 
Francesc Alted




From falted at openlc.org  Thu Oct 16 06:00:01 2003
From: falted at openlc.org (Francesc Alted)
Date: Thu Oct 16 06:00:01 2003
Subject: [Numpy-discussion] How to access to the start of a mmaped numarray object?
In-Reply-To: <200310161312.01994.falted@openlc.org>
References: <200310161312.01994.falted@openlc.org>
Message-ID: <200310161458.21714.falted@openlc.org>

A Dijous 16 Octubre 2003 13:12, Francesc Alted va escriure:
>     PyObject_AsReadBuffer(recarr._data._buffer, &self.mmrbuf, &buflen)
>     (this produces a segmentation fault)
>
>     PyObject_AsReadBuffer(recarr._data.__buffer__(), &self.mmrbuf, &buflen)
>     (another seg fault)

Ooops, sorry, the segmentation fault was taking place *after* that statement.
This code seems to work well. Anyways.

-- 
Francesc Alted




From jmiller at stsci.edu  Fri Oct 17 05:51:05 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Fri Oct 17 05:51:05 2003
Subject: [Numpy-discussion] numpy welcomes Peter Verveer as a new developer
Message-ID: <1066395037.3459.183.camel@localhost.localdomain>

By vote of the existing numpy developers, Peter Verveer has been added
to the project as a developer.  Peter has been working on a
multi-dimensional image processing package soon to be called
numarray.nd_image.  This is a great day for numarray and numpy!

Welcome Peter.

Todd

-- 
Todd Miller <jmiller at stsci.edu>




From 533ryjx at yahoo.com  Sat Oct 18 08:18:01 2003
From: 533ryjx at yahoo.com (Branden Figueroa)
Date: Sat Oct 18 08:18:01 2003
Subject: [Numpy-discussion] CASINO Online: Get $1000 Just to Play - Win a FERRARI.................. dqvhhppm zkkqbcwmc
Message-ID: <t8p988kl-4vf33f2@53a.7t.x.9b8u>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031018/a801252a/attachment.html>

From edcjones at erols.com  Sun Oct 19 02:22:02 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Sun Oct 19 02:22:02 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <3F91BC37.7060200@erols.com>

#! /usr/bin/env python

# Python 2.3.2, numarray 0.7
import numarray

def fun1(code, scale):
     arr1 = numarray.ones((4,4), code)
     arr2 = scale * arr1
     arr3 = numarray.ones((4,4), code)
     # Bug appears at second multiply.
     arr4 = scale * arr3

def fun2(code, scale):
     arr = numarray.ones((4,4), code)
     arr2 = scale * arr
     # Bug appears at second multiply.
     arr3 = scale * arr

# These calls fail when "scale" is too big for "code":

#   File 
"/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
653, in __rmul__
#    def __rmul__(self, operand): return ufunc.multiply(operand, self)
# ValueError: invalid shape tuple

#fun2('Int16', 100000)
fun2('UInt8' , -1)




From jmiller at stsci.edu  Sun Oct 19 07:20:02 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Sun Oct 19 07:20:02 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <3F91BC37.7060200@erols.com>
References: <3F91BC37.7060200@erols.com>
Message-ID: <1066564851.3463.3.camel@localhost.localdomain>

I confirmed this and logged it on Source Forge as numpy-Numarray
Bugs-826311 [Numpy-discussion] Possible bug in scalar * array.

I don't have a fix yet.

Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun1(code, scale):
>      arr1 = numarray.ones((4,4), code)
>      arr2 = scale * arr1
>      arr3 = numarray.ones((4,4), code)
>      # Bug appears at second multiply.
>      arr4 = scale * arr3
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jmiller at stsci.edu>




From nadavh at VisionSense.com  Sun Oct 19 08:13:21 2003
From: nadavh at VisionSense.com (Nadav Horesh)
Date: Sun Oct 19 08:13:21 2003
Subject: [Numpy-discussion] numarray.convolve bug and a fix
Message-ID: <1066566925.2830.29.camel@Nadav.Envision.co.il>

numarray.convolve.correlate2d (and probably some other functions in the
convolve module) doesn't work with the option fft=1.

Fix:
 in iraf_frame.py line 28 and Convolve.py line 136 replace
 "type=" by "typecode="

Nadav.




From Promoteing at 2911.net  Sun Oct 19 18:25:17 2003
From: Promoteing at 2911.net (Director)
Date: Sun Oct 19 18:25:17 2003
Subject: [Numpy-discussion] Marketing Support
Message-ID: <E1ABOXd-0001sn-Cz@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Karl Jackson
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From Promoteing at 2911.net  Mon Oct 20 04:01:40 2003
From: Promoteing at 2911.net (Director)
Date: Mon Oct 20 04:01:40 2003
Subject: [Numpy-discussion] Marketing
Message-ID: <E1ABXmR-0002Fp-QC@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Robert Jones
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From jmiller at stsci.edu  Mon Oct 20 12:41:14 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 20 12:41:14 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <3F91BC37.7060200@erols.com>
References: <3F91BC37.7060200@erols.com>
Message-ID: <1066678612.14017.197.camel@halloween.stsci.edu>

I tracked down the problem to some (relatively) new overflow checking
code which detects the overflow of the scalar -1 as it is assigned to an
array pseudo buffer of type UInt8.  This error was mishandled, and hence
was transformed into an invalid shape tuple (you gotta smile :-)).  The
*2nd* call is where the exception shows up because of caching logic.

I talked this over with Perry and we concluded that it's probably a good
thing to trap the out of range scalar values before using them.  Thus,
we're proposing to fix the error handling,  but to make the calls in
question raise an overflow exception on the first call.  We are
interested in hearing other opinions however.  Comments?

Regards,
Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Mon Oct 20 17:44:22 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 20 17:44:22 2003
Subject: [Numpy-discussion] numarray.convolve bug and a fix
In-Reply-To: <1066566925.2830.29.camel@Nadav.Envision.co.il>
References: <1066566925.2830.29.camel@Nadav.Envision.co.il>
Message-ID: <1066684186.14017.228.camel@halloween.stsci.edu>

Thanks Nadav,

I applied your suggestion to CVS and added a couple self-tests.

Regards,
Todd

On Sun, 2003-10-19 at 08:35, Nadav Horesh wrote:
> numarray.convolve.correlate2d (and probably some other functions in the
> convolve module) doesn't work with the option fft=1.
> 
> Fix:
>  in iraf_frame.py line 28 and Convolve.py line 136 replace
>  "type=" by "typecode="
> 
> Nadav.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From russ at coldstonelabs.org  Mon Oct 20 22:30:03 2003
From: russ at coldstonelabs.org (Russell Valentine)
Date: Mon Oct 20 22:30:03 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
Message-ID: <20031020232836.53359a6c.russ@coldstonelabs.org>

Hello,

   It may be my fault, but I think the following behaviour is odd. If I
try to change a array to a string it seems like it adds a lot of extra
zero characters. Take the following script attached as a example, it gives
me this output.

ta.tostring is not equal
Zero characters - 25
255 characters - 3
tast is equal
Zero characters - 4
255 characters - 3

tostring() is so much more faster than the second way, but it isn't giving
me the desired results. Have I done something wrong? I'm using Numeric
23.1

Thanks for your help.


Russell Valentine
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: NumericTest.py
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031020/7663b06f/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031020/7663b06f/attachment.sig>

From falted at openlc.org  Tue Oct 21 02:02:29 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct 21 02:02:29 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <1066678612.14017.197.camel@halloween.stsci.edu>
References: <3F91BC37.7060200@erols.com> <1066678612.14017.197.camel@halloween.stsci.edu>
Message-ID: <200310210953.30323.falted@openlc.org>

A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?

You mean implementing range checking in numarray objects? In my opinion,
that would be a very nice feature, although I don't know how that would
affect the assignment performance.

-- 
Francesc Alted




From jmiller at stsci.edu  Tue Oct 21 07:34:02 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 07:34:02 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <200310210953.30323.falted@openlc.org>
References: <3F91BC37.7060200@erols.com>
	<1066678612.14017.197.camel@halloween.stsci.edu> 
	<200310210953.30323.falted@openlc.org>
Message-ID: <1066746638.1407.150.camel@halloween.stsci.edu>

On Tue, 2003-10-21 at 03:53, Francesc Alted wrote:
> A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> > I talked this over with Perry and we concluded that it's probably a good
> > thing to trap the out of range scalar values before using them.  Thus,
> > we're proposing to fix the error handling,  but to make the calls in
> > question raise an overflow exception on the first call.  We are
> > interested in hearing other opinions however.  Comments?
> 
> You mean implementing range checking in numarray objects? In my opinion,
> that would be a very nice feature, although I don't know how that would
> affect the assignment performance.

I don't anticipate any impact on performance for the limited scope we
were proposing:  overflow checking for the scalar parameters of binary
ufuncs.  There are other areas where overflow checking could be employed
but won't be.  So, trying to create a more coherent picture,

Here is where we will check for overflows:

1. fromlist(), if you specify check_overflow=1.  
2. scalar parameters of binary ufuncs.  So 1+a will make sure "1" fits
in the array implied by a.type().
3. non-array-sequence parameters of binary ufuncs.  So add(a,[1,2,3])
ensures that [1,2,3] can be stored in an array of the type implied by
array a. 
4. The multiply ufunc.
5. a[<single_element_index>] = x  whenever a._check_overflow is 1.

Here is where we won't check for overflows:

1. array(), or fromlist() by default.
2. most binary ufuncs.  So a+b won't check, assuming a and b are both
arrays.
3. a[<block_of_elements_index>] = b, regardless of a._check_overflow.

Comments?  Anything grossly inconsistent here?

> -- 
> Francesc Alted
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From nadavh at visionsense.com  Tue Oct 21 09:15:06 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 09:15:06 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E8066907@exchange2k.envision.co.il>

You have to convert ta to an (Unsigned)Int8 in order to make it work:

ta = N.array([0, 255, 255, 255,0,0,0], N.UnsignedInt8)
.......................................^^^^^^^^^^^^^^

The default integer type is 32 bits signed.

 Nadav.

-----Original Message-----
From:	Francesc Alted [mailto:falted at openlc.org]
Sent:	Tue 21-Oct-03 09:53
To:	numpy-discussion
Cc:	
Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?

You mean implementing range checking in numarray objects? In my opinion,
that would be a very nice feature, although I don't know how that would
affect the assignment performance.

-- 
Francesc Alted



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion






From nadavh at visionsense.com  Tue Oct 21 09:16:09 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 09:16:09 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E8066906@exchange2k.envision.co.il>

As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
* State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
* State 2: Raise exception as suggested.
* State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:

>>> a = array((100,200,128), type=UInt8)
>>> a+a
array([200, 144,   0], type=UInt8)
>>> a*2
array([200, 255, 255], type=UInt8)

  Nadav

-----Original Message-----
From:	Todd Miller [mailto:jmiller at stsci.edu]
Sent:	Mon 20-Oct-03 21:36
To:	Edward C. Jones
Cc:	numpy-discussion
Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
I tracked down the problem to some (relatively) new overflow checking
code which detects the overflow of the scalar -1 as it is assigned to an
array pseudo buffer of type UInt8.  This error was mishandled, and hence
was transformed into an invalid shape tuple (you gotta smile :-)).  The
*2nd* call is where the exception shows up because of caching logic.

I talked this over with Perry and we concluded that it's probably a good
thing to trap the out of range scalar values before using them.  Thus,
we're proposing to fix the error handling,  but to make the calls in
question raise an overflow exception on the first call.  We are
interested in hearing other opinions however.  Comments?

Regards,
Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion







From jmiller at stsci.edu  Tue Oct 21 09:59:28 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 09:59:28 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
In-Reply-To: <20031020232836.53359a6c.russ@coldstonelabs.org>
References: <20031020232836.53359a6c.russ@coldstonelabs.org>
Message-ID: <1066742169.955.51.camel@halloween.stsci.edu>

I think the problem is that the default integer precision is most likely
32-bits, and you appear to be assuming it will be 8-bits.  If you
declare your array using typecode=Numeric.UInt8 as an extra parameter,
you will force the type to match your assumption and things will work
out as you expect.

Regards,
Todd

On Tue, 2003-10-21 at 00:28, Russell Valentine wrote:
> Hello,
> 
>    It may be my fault, but I think the following behaviour is odd. If I
> try to change a array to a string it seems like it adds a lot of extra
> zero characters. Take the following script attached as a example, it gives
> me this output.
> 
> ta.tostring is not equal
> Zero characters - 25
> 255 characters - 3
> tast is equal
> Zero characters - 4
> 255 characters - 3
> 
> tostring() is so much more faster than the second way, but it isn't giving
> me the desired results. Have I done something wrong? I'm using Numeric
> 23.1
> 
> Thanks for your help.
> 
> 
> Russell Valentine
> ----
> 

> #!/bin/env python
> 
> import string
> import Numeric
> 
> 
> ta = Numeric.array([0, 255, 255, 255,0,0,0])
> compare_string = "\x00\xff\xff\xff\x00\x00\x00"
> if ta.tostring() == compare_string:
>     print "ta.tostring is equal"
> else:
>     print "ta.tostring is not equal"
> 
> print "Zero characters - "+str(ta.tostring().count("\x00"))
> print "255 characters - "+str(ta.tostring().count("\xff"))
> 
> tast = ""
> for value in ta:
>     tast += chr(value)
> 
> if tast == compare_string:
>     print "tast is equal"
> else:
>     print "tast is not equal"
> 
> print "Zero characters - "+str(tast.count("\x00"))
> print "255 characters - "+str(tast.count("\xff"))
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Tue Oct 21 10:33:11 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 10:33:11 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: 	<07C6A61102C94148B8104D42DE95F7E8066906@exchange2k.envision.co.il>
References: 	<07C6A61102C94148B8104D42DE95F7E8066906@exchange2k.envision.co.il>
Message-ID: <1066749150.955.167.camel@halloween.stsci.edu>

On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> * State 2: Raise exception as suggested.
> * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> 
> >>> a = array((100,200,128), type=UInt8)
> >>> a+a
> array([200, 144,   0], type=UInt8)
> >>> a*2
> array([200, 255, 255], type=UInt8)
> 
>   Nadav

This sounds like an attempt to turn a bug fix into a coherent plan. :)

We could implement what you're describing here a lot like we handle IEEE
floating point,  but I'm wondering if we should.  I think state 3 is
marginally portable, so I'm not sure we should support it,  but if we
did, what would we use it for? 

Similarly,  if we support both states 1 and 2,  is anyone going to be
sufficiently on the ball to know the difference and set their error
handling appropriately?  Or, are 99.9% of the people going to just use
whatever the default is?  If the latter is the case, we should just
implement "the default" and keep life simple.

I'm not opposed to this if there are valid uses for it,  but we should
know those reasons before implementing, and I don't.

Thanks for the ideas,
Todd

> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Mon 20-Oct-03 21:36
> To:	Edward C. Jones
> Cc:	numpy-discussion
> Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> I tracked down the problem to some (relatively) new overflow checking
> code which detects the overflow of the scalar -1 as it is assigned to an
> array pseudo buffer of type UInt8.  This error was mishandled, and hence
> was transformed into an invalid shape tuple (you gotta smile :-)).  The
> *2nd* call is where the exception shows up because of caching logic.
> 
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?
> 
> Regards,
> Todd
> 
> On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > #! /usr/bin/env python
> > 
> > # Python 2.3.2, numarray 0.7
> > import numarray
> > 
> > def fun2(code, scale):
> >      arr = numarray.ones((4,4), code)
> >      arr2 = scale * arr
> >      # Bug appears at second multiply.
> >      arr3 = scale * arr
> > 
> > # These calls fail when "scale" is too big for "code":
> > 
> > #   File 
> > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > 653, in __rmul__
> > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > # ValueError: invalid shape tuple
> > 
> > #fun2('Int16', 100000)
> > fun2('UInt8' , -1)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > http://www.enterpriselinuxforum.com
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From edcjones at erols.com  Tue Oct 21 12:11:15 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Tue Oct 21 12:11:15 2003
Subject: [Numpy-discussion] Doc bug for NA_New...
Message-ID: <3F956960.4050003@erols.com>

The source code for NA_vNewArray says "Call with buffer==NULL to 
allocate storage." This is handled in NA_NewAllFromBuffer and so applies 
to all the NA_New... functions. This needs to be mentioned in the 
documentation.

Ed Jones




From Chris.Barker at noaa.gov  Tue Oct 21 15:09:03 2003
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Tue Oct 21 15:09:03 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
References: <20031020232836.53359a6c.russ@coldstonelabs.org>
Message-ID: <3F95447A.F779AC0F@noaa.gov>

Russell Valentine wrote:

>    It may be my fault, but I think the following behaviour is odd. If I
> try to change a array to a string it seems like it adds a lot of extra
> zero characters. Take the following script attached as a example, it gives
> me this output.

You've misunderstood what tostring() is supposed to do. It takes the
BINARY data representing the array, and dumps it into a Python string as
a string of bytes. It is NOT doing a chr() on each element. As an
example:

>>> a = array((1.0))
>>> # a is now a one element Python Float (C double, 8 bytes)
>>> s = a.tostring()
>>> len(s)
8
>>> print repr(s)
'\x00\x00\x00\x00\x00\x00\xf0?'
>>>

And there are your 8 bytes.

By the way, in your code:
tast = ""
for value in ta:
    tast += chr(value)

you could probably speed it up quite a bit by doing this instead:
tast = []
for value in ta:
    tast.append(value)
tast = "".join(tast)

Using += with a string creates a new string, one charactor longer, each
time. Appending to an a list is much faster, and the string join method
is pretty quick also.


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

Chris.Barker at noaa.gov



From jmiller at stsci.edu  Tue Oct 21 16:07:16 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 16:07:16 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: 	<07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
References: 	<07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
Message-ID: <1066769230.955.270.camel@halloween.stsci.edu>

On Tue, 2003-10-21 at 15:04, Nadav Horesh wrote:
> To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).

I see your point about the "singularity", but because of the new scalar
rules in numarray, checking for overflow seems necessary:  there is a
hidden downcast from the scalar to the array type for scalar_vector and
vector_scalar operations.  

> I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. 

My point was that without a reason to value consistency between the
overflow results of __add__ and __mul__, and with no guarantee that the
consistency is really obtainable anyway,  why worry about it?

> Why the __add__ operator should have the risk of being nonportable and __mul__ should not?

The reason __add__ and __mul__ are treated differently is that there is
a different "probability" of overflow for each.  With __mul__, overflow
is much more likely, so we deal with it and try to flag the elements
where it occurred.  With __add__, we don't want to pay the significant
performance penalty of checking for overflow.

> Which state should be the default?
> There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).

Your arguments all make sense to me Nadav, but it ultimately boils down
to what level of overflow checking we have the will to implement.  Right
now, we have the will to fix the bug in the vector scalar error handling
and a simple choice of what to do with one particular new error we've
uncovered: ignore it or trap it.

Regards,
Todd

> 
>   Nadav.
> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Tue 21-Oct-03 17:12
> To:	Nadav Horesh
> Cc:	Edward C. Jones; numpy-discussion
> Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
> On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> > As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> > * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> > * State 2: Raise exception as suggested.
> > * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> > 
> > >>> a = array((100,200,128), type=UInt8)
> > >>> a+a
> > array([200, 144,   0], type=UInt8)
> > >>> a*2
> > array([200, 255, 255], type=UInt8)
> > 
> >   Nadav
> 
> This sounds like an attempt to turn a bug fix into a coherent plan. :)
> 
> We could implement what you're describing here a lot like we handle IEEE
> floating point,  but I'm wondering if we should.  I think state 3 is
> marginally portable, so I'm not sure we should support it,  but if we
> did, what would we use it for? 
> 
> Similarly,  if we support both states 1 and 2,  is anyone going to be
> sufficiently on the ball to know the difference and set their error
> handling appropriately?  Or, are 99.9% of the people going to just use
> whatever the default is?  If the latter is the case, we should just
> implement "the default" and keep life simple.
> 
> I'm not opposed to this if there are valid uses for it,  but we should
> know those reasons before implementing, and I don't.
> 
> Thanks for the ideas,
> Todd
> 
> > 
> > -----Original Message-----
> > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > Sent:	Mon 20-Oct-03 21:36
> > To:	Edward C. Jones
> > Cc:	numpy-discussion
> > Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> > I tracked down the problem to some (relatively) new overflow checking
> > code which detects the overflow of the scalar -1 as it is assigned to an
> > array pseudo buffer of type UInt8.  This error was mishandled, and hence
> > was transformed into an invalid shape tuple (you gotta smile :-)).  The
> > *2nd* call is where the exception shows up because of caching logic.
> > 
> > I talked this over with Perry and we concluded that it's probably a good
> > thing to trap the out of range scalar values before using them.  Thus,
> > we're proposing to fix the error handling,  but to make the calls in
> > question raise an overflow exception on the first call.  We are
> > interested in hearing other opinions however.  Comments?
> > 
> > Regards,
> > Todd
> > 
> > On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > > #! /usr/bin/env python
> > > 
> > > # Python 2.3.2, numarray 0.7
> > > import numarray
> > > 
> > > def fun2(code, scale):
> > >      arr = numarray.ones((4,4), code)
> > >      arr2 = scale * arr
> > >      # Bug appears at second multiply.
> > >      arr3 = scale * arr
> > > 
> > > # These calls fail when "scale" is too big for "code":
> > > 
> > > #   File 
> > > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > > 653, in __rmul__
> > > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > > # ValueError: invalid shape tuple
> > > 
> > > #fun2('Int16', 100000)
> > > fun2('UInt8' , -1)
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > > http://www.enterpriselinuxforum.com
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Numpy-discussion at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > -- 
> > Todd Miller 			
> > Space Telescope Science Institute
> > 3700 San Martin Drive
> > Baltimore MD, 21030
> > (410) 338 - 4576
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by OSDN developer relations
> > Here's your chance to show off your extensive product knowledge
> > We want to know what you know. Tell us and you have a chance to win $100
> > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > 
> > 
> > 
> > 
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From russ at coldstonelabs.org  Tue Oct 21 17:00:10 2003
From: russ at coldstonelabs.org (Russell Valentine)
Date: Tue Oct 21 17:00:10 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
In-Reply-To: <1066742169.955.51.camel@halloween.stsci.edu>
References: <20031020232836.53359a6c.russ@coldstonelabs.org>
	<1066742169.955.51.camel@halloween.stsci.edu>
Message-ID: <20031021164435.36801a7f.russ@coldstonelabs.org>



I understand my error. Everyone who responded, you have my thanks.


Russell Valentine


On 21 Oct 2003 09:16:08 -0400
Todd Miller <jmiller at stsci.edu> wrote:

> I think the problem is that the default integer precision is most likely
> 32-bits, and you appear to be assuming it will be 8-bits.  If you
> declare your array using typecode=Numeric.UInt8 as an extra parameter,
> you will force the type to match your assumption and things will work
> out as you expect.
> 
> Regards,
> Todd
> 
> On Tue, 2003-10-21 at 00:28, Russell Valentine wrote:
> > Hello,
> > 
> >    It may be my fault, but I think the following behaviour is odd. If
> >    I
> > try to change a array to a string it seems like it adds a lot of extra
> > zero characters. Take the following script attached as a example, it
> > gives me this output.
> > 
> > ta.tostring is not equal
> > Zero characters - 25
> > 255 characters - 3
> > tast is equal
> > Zero characters - 4
> > 255 characters - 3
> > 
> > tostring() is so much more faster than the second way, but it isn't
> > giving me the desired results. Have I done something wrong? I'm using
> > Numeric 23.1
> > 
> > Thanks for your help.
> > 
> > 
> > Russell Valentine
> > ----
> > 
> 
> > #!/bin/env python
> > 
> > import string
> > import Numeric
> > 
> > 
> > ta = Numeric.array([0, 255, 255, 255,0,0,0])
> > compare_string = "\x00\xff\xff\xff\x00\x00\x00"
> > if ta.tostring() == compare_string:
> >     print "ta.tostring is equal"
> > else:
> >     print "ta.tostring is not equal"
> > 
> > print "Zero characters - "+str(ta.tostring().count("\x00"))
> > print "255 characters - "+str(ta.tostring().count("\xff"))
> > 
> > tast = ""
> > for value in ta:
> >     tast += chr(value)
> > 
> > if tast == compare_string:
> >     print "tast is equal"
> > else:
> >     print "tast is not equal"
> > 
> > print "Zero characters - "+str(tast.count("\x00"))
> > print "255 characters - "+str(tast.count("\xff"))
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031021/7c43a546/attachment.sig>

From jmiller at stsci.edu  Tue Oct 21 18:13:12 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 18:13:12 2003
Subject: [Numpy-discussion] Doc bug for NA_New...
In-Reply-To: <3F956960.4050003@erols.com>
References: <3F956960.4050003@erols.com>
Message-ID: <1066774740.955.274.camel@halloween.stsci.edu>

I added a comment to each of the function definitions.

Thanks,
Todd

On Tue, 2003-10-21 at 13:14, Edward C. Jones wrote:
> The source code for NA_vNewArray says "Call with buffer==NULL to 
> allocate storage." This is handled in NA_NewAllFromBuffer and so applies 
> to all the NA_New... functions. This needs to be mentioned in the 
> documentation.
> 
> Ed Jones
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From nadavh at visionsense.com  Tue Oct 21 20:05:10 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 20:05:10 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>

To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).

I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. Why the __add__ operator should have the risk of being nonportable and __mul__ should not?

Which state should be the default?
There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).

  Nadav.

-----Original Message-----
From:	Todd Miller [mailto:jmiller at stsci.edu]
Sent:	Tue 21-Oct-03 17:12
To:	Nadav Horesh
Cc:	Edward C. Jones; numpy-discussion
Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> * State 2: Raise exception as suggested.
> * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> 
> >>> a = array((100,200,128), type=UInt8)
> >>> a+a
> array([200, 144,   0], type=UInt8)
> >>> a*2
> array([200, 255, 255], type=UInt8)
> 
>   Nadav

This sounds like an attempt to turn a bug fix into a coherent plan. :)

We could implement what you're describing here a lot like we handle IEEE
floating point,  but I'm wondering if we should.  I think state 3 is
marginally portable, so I'm not sure we should support it,  but if we
did, what would we use it for? 

Similarly,  if we support both states 1 and 2,  is anyone going to be
sufficiently on the ball to know the difference and set their error
handling appropriately?  Or, are 99.9% of the people going to just use
whatever the default is?  If the latter is the case, we should just
implement "the default" and keep life simple.

I'm not opposed to this if there are valid uses for it,  but we should
know those reasons before implementing, and I don't.

Thanks for the ideas,
Todd

> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Mon 20-Oct-03 21:36
> To:	Edward C. Jones
> Cc:	numpy-discussion
> Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> I tracked down the problem to some (relatively) new overflow checking
> code which detects the overflow of the scalar -1 as it is assigned to an
> array pseudo buffer of type UInt8.  This error was mishandled, and hence
> was transformed into an invalid shape tuple (you gotta smile :-)).  The
> *2nd* call is where the exception shows up because of caching logic.
> 
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?
> 
> Regards,
> Todd
> 
> On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > #! /usr/bin/env python
> > 
> > # Python 2.3.2, numarray 0.7
> > import numarray
> > 
> > def fun2(code, scale):
> >      arr = numarray.ones((4,4), code)
> >      arr2 = scale * arr
> >      # Bug appears at second multiply.
> >      arr3 = scale * arr
> > 
> > # These calls fail when "scale" is too big for "code":
> > 
> > #   File 
> > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > 653, in __rmul__
> > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > # ValueError: invalid shape tuple
> > 
> > #fun2('Int16', 100000)
> > fun2('UInt8' , -1)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > http://www.enterpriselinuxforum.com
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion






From nadavh at visionsense.com  Tue Oct 21 20:26:25 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 20:26:25 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>

To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).

I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. Why the __add__ operator should have the risk of being nonportable and __mul__ should not?

Which state should be the default?
There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).

  Nadav.

-----Original Message-----
From:	Todd Miller [mailto:jmiller at stsci.edu]
Sent:	Tue 21-Oct-03 17:12
To:	Nadav Horesh
Cc:	Edward C. Jones; numpy-discussion
Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> * State 2: Raise exception as suggested.
> * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> 
> >>> a = array((100,200,128), type=UInt8)
> >>> a+a
> array([200, 144,   0], type=UInt8)
> >>> a*2
> array([200, 255, 255], type=UInt8)
> 
>   Nadav

This sounds like an attempt to turn a bug fix into a coherent plan. :)

We could implement what you're describing here a lot like we handle IEEE
floating point,  but I'm wondering if we should.  I think state 3 is
marginally portable, so I'm not sure we should support it,  but if we
did, what would we use it for? 

Similarly,  if we support both states 1 and 2,  is anyone going to be
sufficiently on the ball to know the difference and set their error
handling appropriately?  Or, are 99.9% of the people going to just use
whatever the default is?  If the latter is the case, we should just
implement "the default" and keep life simple.

I'm not opposed to this if there are valid uses for it,  but we should
know those reasons before implementing, and I don't.

Thanks for the ideas,
Todd

> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Mon 20-Oct-03 21:36
> To:	Edward C. Jones
> Cc:	numpy-discussion
> Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> I tracked down the problem to some (relatively) new overflow checking
> code which detects the overflow of the scalar -1 as it is assigned to an
> array pseudo buffer of type UInt8.  This error was mishandled, and hence
> was transformed into an invalid shape tuple (you gotta smile :-)).  The
> *2nd* call is where the exception shows up because of caching logic.
> 
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?
> 
> Regards,
> Todd
> 
> On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > #! /usr/bin/env python
> > 
> > # Python 2.3.2, numarray 0.7
> > import numarray
> > 
> > def fun2(code, scale):
> >      arr = numarray.ones((4,4), code)
> >      arr2 = scale * arr
> >      # Bug appears at second multiply.
> >      arr3 = scale * arr
> > 
> > # These calls fail when "scale" is too big for "code":
> > 
> > #   File 
> > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > 653, in __rmul__
> > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > # ValueError: invalid shape tuple
> > 
> > #fun2('Int16', 100000)
> > fun2('UInt8' , -1)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > http://www.enterpriselinuxforum.com
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion






From nadavh at VisionSense.com  Wed Oct 22 06:59:08 2003
From: nadavh at VisionSense.com (Nadav Horesh)
Date: Wed Oct 22 06:59:08 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <1066769230.955.270.camel@halloween.stsci.edu>
References: 	 <07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
	 <1066769230.955.270.camel@halloween.stsci.edu>
Message-ID: <1066831865.9252.42.camel@Nadav.Envision.co.il>

O.K. got your case (and you certainly have one).

But ...
  in the long run, wouldn't it be nice to give an option to remove all
checking (and thus produce a machine dependent under/overflow treatment)
for those who opt for speed?

 Really enjoyed this discussion,

    Nadav.

On Tue, 2003-10-21 at 22:47, Todd Miller wrote:
> On Tue, 2003-10-21 at 15:04, Nadav Horesh wrote:
> > To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).
> 
> I see your point about the "singularity", but because of the new scalar
> rules in numarray, checking for overflow seems necessary:  there is a
> hidden downcast from the scalar to the array type for scalar_vector and
> vector_scalar operations.  
> 
> > I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. 
> 
> My point was that without a reason to value consistency between the
> overflow results of __add__ and __mul__, and with no guarantee that the
> consistency is really obtainable anyway,  why worry about it?
> 
> > Why the __add__ operator should have the risk of being nonportable and __mul__ should not?
> 
> The reason __add__ and __mul__ are treated differently is that there is
> a different "probability" of overflow for each.  With __mul__, overflow
> is much more likely, so we deal with it and try to flag the elements
> where it occurred.  With __add__, we don't want to pay the significant
> performance penalty of checking for overflow.
> 
> > Which state should be the default?
> > There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).
> 
> Your arguments all make sense to me Nadav, but it ultimately boils down
> to what level of overflow checking we have the will to implement.  Right
> now, we have the will to fix the bug in the vector scalar error handling
> and a simple choice of what to do with one particular new error we've
> uncovered: ignore it or trap it.
> 
> Regards,
> Todd
> 
> > 
> >   Nadav.
> > 
> > -----Original Message-----
> > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > Sent:	Tue 21-Oct-03 17:12
> > To:	Nadav Horesh
> > Cc:	Edward C. Jones; numpy-discussion
> > Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
> > On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> > > As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> > > * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> > > * State 2: Raise exception as suggested.
> > > * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> > > 
> > > >>> a = array((100,200,128), type=UInt8)
> > > >>> a+a
> > > array([200, 144,   0], type=UInt8)
> > > >>> a*2
> > > array([200, 255, 255], type=UInt8)
> > > 
> > >   Nadav
> > 
> > This sounds like an attempt to turn a bug fix into a coherent plan. :)
> > 
> > We could implement what you're describing here a lot like we handle IEEE
> > floating point,  but I'm wondering if we should.  I think state 3 is
> > marginally portable, so I'm not sure we should support it,  but if we
> > did, what would we use it for? 
> > 
> > Similarly,  if we support both states 1 and 2,  is anyone going to be
> > sufficiently on the ball to know the difference and set their error
> > handling appropriately?  Or, are 99.9% of the people going to just use
> > whatever the default is?  If the latter is the case, we should just
> > implement "the default" and keep life simple.
> > 
> > I'm not opposed to this if there are valid uses for it,  but we should
> > know those reasons before implementing, and I don't.
> > 
> > Thanks for the ideas,
> > Todd
> > 
> > > 
> > > -----Original Message-----
> > > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > > Sent:	Mon 20-Oct-03 21:36
> > > To:	Edward C. Jones
> > > Cc:	numpy-discussion
> > > Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> > > I tracked down the problem to some (relatively) new overflow checking
> > > code which detects the overflow of the scalar -1 as it is assigned to an
> > > array pseudo buffer of type UInt8.  This error was mishandled, and hence
> > > was transformed into an invalid shape tuple (you gotta smile :-)).  The
> > > *2nd* call is where the exception shows up because of caching logic.
> > > 
> > > I talked this over with Perry and we concluded that it's probably a good
> > > thing to trap the out of range scalar values before using them.  Thus,
> > > we're proposing to fix the error handling,  but to make the calls in
> > > question raise an overflow exception on the first call.  We are
> > > interested in hearing other opinions however.  Comments?
> > > 
> > > Regards,
> > > Todd
> > > 
> > > On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > > > #! /usr/bin/env python
> > > > 
> > > > # Python 2.3.2, numarray 0.7
> > > > import numarray
> > > > 
> > > > def fun2(code, scale):
> > > >      arr = numarray.ones((4,4), code)
> > > >      arr2 = scale * arr
> > > >      # Bug appears at second multiply.
> > > >      arr3 = scale * arr
> > > > 
> > > > # These calls fail when "scale" is too big for "code":
> > > > 
> > > > #   File 
> > > > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > > > 653, in __rmul__
> > > > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > > > # ValueError: invalid shape tuple
> > > > 
> > > > #fun2('Int16', 100000)
> > > > fun2('UInt8' , -1)
> > > > 
> > > > 
> > > > 
> > > > -------------------------------------------------------
> > > > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > > > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > > > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > > > http://www.enterpriselinuxforum.com
> > > > _______________________________________________
> > > > Numpy-discussion mailing list
> > > > Numpy-discussion at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > -- 
> > > Todd Miller 			
> > > Space Telescope Science Institute
> > > 3700 San Martin Drive
> > > Baltimore MD, 21030
> > > (410) 338 - 4576
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by OSDN developer relations
> > > Here's your chance to show off your extensive product knowledge
> > > We want to know what you know. Tell us and you have a chance to win $100
> > > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Numpy-discussion at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > 
> > > 
> > > 
> > > 
> > -- 
> > Todd Miller 			
> > Space Telescope Science Institute
> > 3700 San Martin Drive
> > Baltimore MD, 21030
> > (410) 338 - 4576
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by OSDN developer relations
> > Here's your chance to show off your extensive product knowledge
> > We want to know what you know. Tell us and you have a chance to win $100
> > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > 
> > 
> > 




From jmiller at stsci.edu  Wed Oct 22 08:27:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct 22 08:27:04 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <1066831865.9252.42.camel@Nadav.Envision.co.il>
References: 	<07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
	<1066769230.955.270.camel@halloween.stsci.edu> 
	<1066831865.9252.42.camel@Nadav.Envision.co.il>
Message-ID: <1066831245.1575.5.camel@halloween.stsci.edu>

On Wed, 2003-10-22 at 10:11, Nadav Horesh wrote:
> O.K. got your case (and you certainly have one).
> 
> But ...
>   in the long run, wouldn't it be nice to give an option to remove all
> checking (and thus produce a machine dependent under/overflow treatment)
> for those who opt for speed?

Yes,  it would be nice,  but... not nice enough to "actually do it."  
If it is important enough,  eventually there will be a clamor for action
which I don't see right now.

> 
>  Really enjoyed this discussion,
> 
>     Nadav.

Me too.  Thanks for the input,

Todd

> 
> On Tue, 2003-10-21 at 22:47, Todd Miller wrote:
> > On Tue, 2003-10-21 at 15:04, Nadav Horesh wrote:
> > > To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).
> > 
> > I see your point about the "singularity", but because of the new scalar
> > rules in numarray, checking for overflow seems necessary:  there is a
> > hidden downcast from the scalar to the array type for scalar_vector and
> > vector_scalar operations.  
> > 
> > > I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. 
> > 
> > My point was that without a reason to value consistency between the
> > overflow results of __add__ and __mul__, and with no guarantee that the
> > consistency is really obtainable anyway,  why worry about it?
> > 
> > > Why the __add__ operator should have the risk of being nonportable and __mul__ should not?
> > 
> > The reason __add__ and __mul__ are treated differently is that there is
> > a different "probability" of overflow for each.  With __mul__, overflow
> > is much more likely, so we deal with it and try to flag the elements
> > where it occurred.  With __add__, we don't want to pay the significant
> > performance penalty of checking for overflow.
> > 
> > > Which state should be the default?
> > > There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).
> > 
> > Your arguments all make sense to me Nadav, but it ultimately boils down
> > to what level of overflow checking we have the will to implement.  Right
> > now, we have the will to fix the bug in the vector scalar error handling
> > and a simple choice of what to do with one particular new error we've
> > uncovered: ignore it or trap it.
> > 
> > Regards,
> > Todd
> > 
> > > 
> > >   Nadav.
> > > 
> > > -----Original Message-----
> > > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > > Sent:	Tue 21-Oct-03 17:12
> > > To:	Nadav Horesh
> > > Cc:	Edward C. Jones; numpy-discussion
> > > Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
> > > On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> > > > As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> > > > * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> > > > * State 2: Raise exception as suggested.
> > > > * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> > > > 
> > > > >>> a = array((100,200,128), type=UInt8)
> > > > >>> a+a
> > > > array([200, 144,   0], type=UInt8)
> > > > >>> a*2
> > > > array([200, 255, 255], type=UInt8)
> > > > 
> > > >   Nadav
> > > 
> > > This sounds like an attempt to turn a bug fix into a coherent plan. :)
> > > 
> > > We could implement what you're describing here a lot like we handle IEEE
> > > floating point,  but I'm wondering if we should.  I think state 3 is
> > > marginally portable, so I'm not sure we should support it,  but if we
> > > did, what would we use it for? 
> > > 
> > > Similarly,  if we support both states 1 and 2,  is anyone going to be
> > > sufficiently on the ball to know the difference and set their error
> > > handling appropriately?  Or, are 99.9% of the people going to just use
> > > whatever the default is?  If the latter is the case, we should just
> > > implement "the default" and keep life simple.
> > > 
> > > I'm not opposed to this if there are valid uses for it,  but we should
> > > know those reasons before implementing, and I don't.
> > > 
> > > Thanks for the ideas,
> > > Todd
> > > 
> > > > 
> > > > -----Original Message-----
> > > > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > > > Sent:	Mon 20-Oct-03 21:36
> > > > To:	Edward C. Jones
> > > > Cc:	numpy-discussion
> > > > Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> > > > I tracked down the problem to some (relatively) new overflow checking
> > > > code which detects the overflow of the scalar -1 as it is assigned to an
> > > > array pseudo buffer of type UInt8.  This error was mishandled, and hence
> > > > was transformed into an invalid shape tuple (you gotta smile :-)).  The
> > > > *2nd* call is where the exception shows up because of caching logic.
> > > > 
> > > > I talked this over with Perry and we concluded that it's probably a good
> > > > thing to trap the out of range scalar values before using them.  Thus,
> > > > we're proposing to fix the error handling,  but to make the calls in
> > > > question raise an overflow exception on the first call.  We are
> > > > interested in hearing other opinions however.  Comments?
> > > > 
> > > > Regards,
> > > > Todd
> > > > 
> > > > On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > > > > #! /usr/bin/env python
> > > > > 
> > > > > # Python 2.3.2, numarray 0.7
> > > > > import numarray
> > > > > 
> > > > > def fun2(code, scale):
> > > > >      arr = numarray.ones((4,4), code)
> > > > >      arr2 = scale * arr
> > > > >      # Bug appears at second multiply.
> > > > >      arr3 = scale * arr
> > > > > 
> > > > > # These calls fail when "scale" is too big for "code":
> > > > > 
> > > > > #   File 
> > > > > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > > > > 653, in __rmul__
> > > > > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > > > > # ValueError: invalid shape tuple
> > > > > 
> > > > > #fun2('Int16', 100000)
> > > > > fun2('UInt8' , -1)
> > > > > 
> > > > > 
> > > > > 
> > > > > -------------------------------------------------------
> > > > > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > > > > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > > > > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > > > > http://www.enterpriselinuxforum.com
> > > > > _______________________________________________
> > > > > Numpy-discussion mailing list
> > > > > Numpy-discussion at lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > > -- 
> > > > Todd Miller 			
> > > > Space Telescope Science Institute
> > > > 3700 San Martin Drive
> > > > Baltimore MD, 21030
> > > > (410) 338 - 4576
> > > > 
> > > > 
> > > > 
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by OSDN developer relations
> > > > Here's your chance to show off your extensive product knowledge
> > > > We want to know what you know. Tell us and you have a chance to win $100
> > > > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > > > _______________________________________________
> > > > Numpy-discussion mailing list
> > > > Numpy-discussion at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > > 
> > > > 
> > > > 
> > > > 
> > > -- 
> > > Todd Miller 			
> > > Space Telescope Science Institute
> > > 3700 San Martin Drive
> > > Baltimore MD, 21030
> > > (410) 338 - 4576
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by OSDN developer relations
> > > Here's your chance to show off your extensive product knowledge
> > > We want to know what you know. Tell us and you have a chance to win $100
> > > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Numpy-discussion at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > 
> > > 
> > > 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From Promoteing at 2911.net  Wed Oct 22 13:46:17 2003
From: Promoteing at 2911.net (Marketing)
Date: Wed Oct 22 13:46:17 2003
Subject: [Numpy-discussion] Marketing Details
Message-ID: <E1ACPTC-0003bL-9m@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Robert Jones
Sales & Marketing
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From cjw at sympatico.ca  Wed Oct 22 18:29:12 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Wed Oct 22 18:29:12 2003
Subject: [Numpy-discussion] Documentation using PyDoc
Message-ID: <3F971078.3030309@sympatico.ca>

[Message copied to comp.lang.python]

I am building a module which is based on the numarray package and its 
sub-packages.

I am proposing to use PyDoc to document this module.  The problem is 
that PyDoc generates links to documentation on the imported modules and 
expects to find HTML files in the style: nameOfImportedModule.html.

The numarray documentation is not in this style.

Is there some way that I can guide PyDoc in the generation of names to 
the imported links?

Supposing I create my own links, how can I ensure that these 
automatically call the appropriate node in the numarray tree?

Is there any possibility that the numarray documentation could be 
generated by PyDoc?

I would appreciate any advice.

Colin W.

PS I don't see any documentation on the generic module.







From edcjones at erols.com  Thu Oct 23 10:47:31 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Thu Oct 23 10:47:31 2003
Subject: [Numpy-discussion] Incorrect OverflowError?
Message-ID: <3F97F56E.5000700@erols.com>

#! /usr/bin/env python

import numarray
from numarray.numerictypes import *

# I run Gentoo 1.4 Linux with gcc 3.2.2.

numarray.Error.setMode(all='ignore')

arr = numarray.zeros((1,), Float64)
arr[0] = 4000000000.0
print '%f' % arr[0]
try:
     arr[0] = 4000000000
     print "Doesn't get here."
except OverflowError, s:
     print 'Python OverflowError raised'
     print s
# OverflowError: long int too large to convert to int

# The Python long "4000000000" can be represented as a C double.
# If the OverflowError came from numarray, why was an exception raised?
# Are these problems bugs?




From cjw at sympatico.ca  Thu Oct 23 12:27:11 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Thu Oct 23 12:27:11 2003
Subject: [Numpy-discussion] Symmetry of functions
Message-ID: <3F982AC5.8000806@sympatico.ca>

A suggestion:

fromstring accepts a string - tostring returns a string
fromfile accepts a file        -  tofile returns None

This is to suggest that generic.tofile be modified
to return the file object, which may be open or
closed.

Colin W.





From cjw at sympatico.ca  Thu Oct 23 13:31:11 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Thu Oct 23 13:31:11 2003
Subject: [Numpy-discussion] Documentation using PyDoc
In-Reply-To: <1066916588.19211.62.camel@halloween.stsci.edu>
References: <3F971078.3030309@sympatico.ca> <1066916588.19211.62.camel@halloween.stsci.edu>
Message-ID: <3F97EA03.10101@sympatico.ca>

Todd,

Many thanks, you've suggested the obvious (now) - generate my own.

Thanks, I should have thought of this.

The only relatively minor problem is that my package will need to update 
thes generated files as numarray progresses.

Colin W.

PS Richard Jones has suggested ePyDoc as an enhanced PyDoc.  I'll look 
at that.

Todd Miller wrote:

>On Wed, 2003-10-22 at 19:19, Colin J. Williams wrote:
>  
>
>>[Message copied to comp.lang.python]
>>
>>I am building a module which is based on the numarray package and its 
>>sub-packages.
>>
>>I am proposing to use PyDoc to document this module.  The problem is 
>>that PyDoc generates links to documentation on the imported modules and 
>>expects to find HTML files in the style: nameOfImportedModule.html.
>>
>>    
>>
>I'm not sure I fully understand the problem,  but I just tried:
>
>  
>
>>>>import pydoc
>>>>pydoc.writedoc("numarray.generic")
>>>>        
>>>>
>
>This produced numarray.generic.html.
>
>  
>
>>The numarray documentation is not in this style.
>>    
>>
>
>The manual certainly isn't,  but is Python's own manual in this style?
> 
>  
>
>>Is there some way that I can guide PyDoc in the generation of names to 
>>the imported links?
>>    
>>
>
>See above.
>
>  
>
>>Supposing I create my own links, how can I ensure that these 
>>automatically call the appropriate node in the numarray tree?
>>
>>Is there any possibility that the numarray documentation could be 
>>generated by PyDoc?
>>    
>>
>
>Yes and no.  Numarray already has doc-strings which probably need more
>work. The numarray manual is not going to suddenly transform into pydoc
>format.
> 
>  
>
>>I would appreciate any advice.
>>    
>>
>
>That's my $.02
>
>  
>
>>Colin W.
>>
>>PS I don't see any documentation on the generic module.
>>
>>    
>>
>What information exists is recorded in a combination of the manual, the
>generic.py doc-strings, and Doc/design.txt.  design.txt looks like it
>has some bit-rot (especially the C-API).
>
>There's probably not as much info as you want,  but I think what you're
>trying to do (create an NDArray or NumArray subclass) is at the
>forefront of numarray development so you may to have to read code or ask
>specific questions to find out what you want to know.
>
>Regards, 
>Todd
>  
>




From jmiller at stsci.edu  Thu Oct 23 13:31:25 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Thu Oct 23 13:31:25 2003
Subject: [Numpy-discussion] Incorrect OverflowError?
In-Reply-To: <3F97F56E.5000700@erols.com>
References: <3F97F56E.5000700@erols.com>
Message-ID: <1066940559.19432.118.camel@halloween.stsci.edu>

On Thu, 2003-10-23 at 11:36, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> import numarray
> from numarray.numerictypes import *
> 
> # I run Gentoo 1.4 Linux with gcc 3.2.2.
> 
> numarray.Error.setMode(all='ignore')
> 
> arr = numarray.zeros((1,), Float64)
> arr[0] = 4000000000.0
> print '%f' % arr[0]
> try:
>      arr[0] = 4000000000
>      print "Doesn't get here."
> except OverflowError, s:
>      print 'Python OverflowError raised'
>      print s
> # OverflowError: long int too large to convert to int
> 
> # The Python long "4000000000" can be represented as a C double.
> # If the OverflowError came from numarray, why was an exception raised?
> # Are these problems bugs?
> 
Yes.  The bug was a use of PyLong_AsLong instead of PyLong_AsLongLong. 
Keep looking!  :-)

Thanks,
Todd
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Thu Oct 23 16:04:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Thu Oct 23 16:04:04 2003
Subject: [Numpy-discussion] Documentation using PyDoc
In-Reply-To: <3F971078.3030309@sympatico.ca>
References: <3F971078.3030309@sympatico.ca>
Message-ID: <1066916588.19211.62.camel@halloween.stsci.edu>

On Wed, 2003-10-22 at 19:19, Colin J. Williams wrote:
> [Message copied to comp.lang.python]
> 
> I am building a module which is based on the numarray package and its 
> sub-packages.
> 
> I am proposing to use PyDoc to document this module.  The problem is 
> that PyDoc generates links to documentation on the imported modules and 
> expects to find HTML files in the style: nameOfImportedModule.html.
> 
I'm not sure I fully understand the problem,  but I just tried:

>>> import pydoc
>>> pydoc.writedoc("numarray.generic")

This produced numarray.generic.html.

> The numarray documentation is not in this style.

The manual certainly isn't,  but is Python's own manual in this style?
 
> Is there some way that I can guide PyDoc in the generation of names to 
> the imported links?

See above.

> Supposing I create my own links, how can I ensure that these 
> automatically call the appropriate node in the numarray tree?
> 
> Is there any possibility that the numarray documentation could be 
> generated by PyDoc?

Yes and no.  Numarray already has doc-strings which probably need more
work. The numarray manual is not going to suddenly transform into pydoc
format.
 
> I would appreciate any advice.

That's my $.02

> Colin W.
> 
> PS I don't see any documentation on the generic module.
> 
What information exists is recorded in a combination of the manual, the
generic.py doc-strings, and Doc/design.txt.  design.txt looks like it
has some bit-rot (especially the C-API).

There's probably not as much info as you want,  but I think what you're
trying to do (create an NDArray or NumArray subclass) is at the
forefront of numarray development so you may to have to read code or ask
specific questions to find out what you want to know.

Regards, 
Todd
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From edcjones at erols.com  Thu Oct 23 18:26:13 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Thu Oct 23 18:26:13 2003
Subject: [Numpy-discussion] NA_getType needs to be documented
Message-ID: <3F9876D9.8040905@erols.com>

"NA_getType" needs to be documented. The following is useful:

     if (!PyArg_ParseTuple(args, "O", &type))
         return NULL;

     temptype = NA_getType(type);
     if (temptype == NULL) return NULL;
     typeno = NA_typeObjectToTypeNo(temptype);
     Py_DECREF(temptype);
     if (typeno < 0) {
         PyErr_Format(PyExc_RuntimeError,
                  "_numarray_init: can't get typeno for type");
         return NULL;
     }

Do other functions in "libnumarraymodule.c" need to be documented?




From mbakker at engr.uga.edu  Fri Oct 24 16:33:07 2003
From: mbakker at engr.uga.edu (Mark Bakker)
Date: Fri Oct 24 16:33:07 2003
Subject: [Numpy-discussion] How can I make a Windows distribution like Numeric
Message-ID: <3F99B56E.4010207@engr.uga.edu>

Hello -

Believe it or not but I have written Python code that will mostly be used on 
Windows. I want to make distribution easier by making a nice Window's install 
just like Numeric. Can anbybody fill me in on what software they use to make the 
Windows binary install?

Thanks, Mark




From zbigk at yahoo.com  Fri Oct 24 16:46:14 2003
From: zbigk at yahoo.com (ADV; . Energy Systems & Electrical Design)
Date: Fri Oct 24 16:46:14 2003
Subject: [Numpy-discussion] ADV:  .  Resume for JOB or Service
Message-ID: <E1ADBb3-0003Ra-L1@sc8-sf-mx2.sourceforge.net>


Rich' S 	Resume	

							Santa Clara, CA 95050


  (408) 482-2840          rrsiek at yahoo.com
 



Electrical Designer &  Drafting


Electro-Mechanical Designer & Drafting



Drafting & Design Shopping Centers; grocery stores, hardware stores, restaurants & residential - housing areas, computer business & fast food units installation & testing; 

Energy systems; Solar Panels, Wind Energy, portable & emergency generators; Factory production lines, food & mechanical process machinery Installations & trouble shooting.  

Equipment & production line installations, MCC, Sensors, Wiring, Alarm, Network, Security, Electrical Design & Installations;  Network Sketches, one line diagrams, and "as is" drawings update. 

Customizing Electronic and Electrical Components & Parts, Layouts electronic and electrical schematic, connectors and mechanical detailing. Use CAD, Windows and applications; Programming & Detailing, Production Equipment, Machinery, Conveyors Spiral Elevator, Fast Cannery Transportation, Electronic and Electrical Components, Parts, Schematics & Layouts, Master Control Center, Can Sheet Metal Oven Rebuilding Project, Combustion Remodeling, PD 5,  PLC setup. 

Designing Electric Cars using AutoCAD, Spreadsheet, Basic, dB; electronic and electrical schematic, Layouts, mechanical detailing & redesigning components for manufacturing, Assembly drawings, Customizing Electronic, Mechanical and Electrical Equipment.

Quotes, supply, bids and job estimating. Customers contact, inspection, project mgmt & supervision of electricians & material handling; Commercial & Residential Project; Mgr. for satellite office & shop. 

Commercial, Industrial, Residential, Fire Alarms, Smoke Detectors, Lights, Plugs, Panels, Power Supply, Electro-Solar Installations, Emergency Generators, Transformers, Power Lines, Fire sprinklers design / control, CAD automation. Foreman, Estimator, Designer & CAD Operator (New & "as is" drawings update)

Hands on electrical installation performing, fitting wires & power lines;  Panels, Light, receptacles & Fuse boxes, emergency power supply, parking lighting & post installation; Installing lamps, switches, alarms, plugs, receptacles, fire alarms, smoke detectors, fire & safety installations; Computer & data network wiring; underground installations & conduit layout, bending and mounting; Job Estimating & bid preparation.

Environmental Energy Systems and Green Building Coordinating Programs;  P E C,  C E C,  PG&E training, Solar Living Institute, High Performance Schools, Health Analyzing, using Solar and Wind Energy Friendly Systems, Savings by Design recommendations & new Title 24 Standards - LEED, CEC, AIA & COTE Ratings. 

Electrical & Electrical Drafting, Electrical Design & management, Site Inspection and Quality Control, coordination with General Contractor, Estimating and Supplying, Document Control & Upgrade, daily performance checking & schedule update. 


Electrical Installations & Service

Solar Energy Installations & Service

Electro-Mechanical Assembly & Service

ELECTRICAL PROJECT MANAGER -  COORDINATOR

ELECTRICAL & MAINTENANCE SERVICE

HANDS ON WIRING & INSTALLATION

ELECTRICAL AND MECHANICAL PROJECTS 



Electrical Installations & Service

Solar Energy Installations & Service

Electro-Mechanical Assembly & Service

ELECTRICAL PROJECT MANAGER -  COORDINATOR

ELECTRICAL & MAINTENANCE SERVICE

HANDS ON WIRING & INSTALLATION

ELECTRICAL AND MECHANICAL PROJECTS 

Sun Tracking  double  SOLAR ENERGY



SOLAR ENERGY SYSTEMS

WIND ENERGY SYSTEMS

SUN TRACKING SYSTEMS

SOLAR PALETTE SYSTEMS

FLYWHEEL STORAGE SYSTEMS



Solar Engineer








From gvermeul at grenoble.cnrs.fr  Fri Oct 24 18:40:07 2003
From: gvermeul at grenoble.cnrs.fr (gvermeul at grenoble.cnrs.fr)
Date: Fri Oct 24 18:40:07 2003
Subject: [Numpy-discussion] How can I make a Windows distribution like Numeric
Message-ID: <200310250136.h9P1amB6009732@grenoble.cnrs.fr>

> Hello -
> 
> Believe it or not but I have written Python code that will mostly be used on 
> Windows. I want to make distribution easier by making a nice Window's install 
> just like Numeric. Can anbybody fill me in on what software they use to make the 
> Windows binary install?
> 
> Thanks, Mark
> 
Check out the documentation on distutils that comes with Python.

Gerard


-------------------------------------------------------------
This message was sent using HTTPS service from CNRS Grenoble.
         --->   https://grenoble.cnrs.fr   <---         





From Promoteing at 2911.net  Fri Oct 24 21:06:08 2003
From: Promoteing at 2911.net (Marketing)
Date: Fri Oct 24 21:06:08 2003
Subject: [Numpy-discussion] Marketing Details
Message-ID: <E1ADFaa-0003wy-Rv@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Robert Jones
Sales & Marketing
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From Promoteing at 2911.net  Sun Oct 26 03:09:07 2003
From: Promoteing at 2911.net (Manager)
Date: Sun Oct 26 03:09:07 2003
Subject: [Numpy-discussion] Marketing Strategy
Message-ID: <E1ADifQ-0005KR-R7@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending
out targeted emails, or want to avoid the work of sending out targeted
emails. We will do it for you!  We can send your email message to your
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Dana DeBolt
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database,
go here www.awayoutofdebtfast.com/dbtremove.htm



From rpraca7 at yahoo.com  Sun Oct 26 03:33:09 2003
From: rpraca7 at yahoo.com (Richard's    R E S U M E)
Date: Sun Oct 26 03:33:09 2003
Subject: [Numpy-discussion] Sr.   Mechanical   &   Design     E n g i n e e r
Message-ID: <E1ADj2P-0008Vh-2W@sc8-sf-mx1.sourceforge.net>

Richard's 	Resume	 for Job, 	Consulting or Service


RESUME


                             RICHARD


OBJECTIVE: 			

        	Sr.  MECHANICAL  &  DESIGN    ENGINEER

  Project Mgr, Electro-Mechanical Design, Mfg, Product Development, R&D, CADD

          Tel: ( 408)  309-7006 	rpraca3 at yahoo.com

EXPERIENCE:
08/93-present          Sr. MECHANICAL & DESIGN ENGINEER, CADD Mgr "Mech-Tronic" 
                   


Engineering, Design & Product Development Service; Project Management, Mfg, Tooling, Product Improvement; Developing Working Product, Design and Prototype Production;  Controlling & Managing testing,  redesign, manufacturing documentation preparation;  
and full realization of Task using technical approach, schedules,  and budget to achieve Final Product.  

Selecting vendors and specialist to supply performance  satisfying customers expectation and to create a new, modern product with advanced properties, quality and market desirable working abilities and sellable values.

Preparing propositions & presentations, Review Manufacturing Process and Quality Control, Inspecting standards, Engineering Computations and Technical Improvements,  Supplying and Production Automation. Project Management & Development. 

Preparing technical documentation, calculations, engineering, design, layouts, drawings, 3D and Solid Modeling, development & propositions. Hard Drive Design, testing, balancing, recalculating and redesign. Manufacturing and Assembly Equipment design and build.  Systems Integration.


Tooling and Operations Development, Implementation & Automation for mass production.  Energy, Electric Vehicles and Computerized Transportation System Design & Implement. Solar Panels. Solid Works, Pro-E, CAD Management and Operations, Analyzing, Micro Station, ACAD 10-2002 & LT, Win 3x & 2000', Net, Internet, Softdesk, Structural Design. Network, Security.

Electrical Design & Installations; Commercial, Industrial, Residential, Fire Alarms, Smoke Detectors, Lights, Plugs, Panels, Power Supply,  Electro - Solar Installations, CADD automation. Dynamics, Kinematics, thermodynamics / heat transfer & FEA analyzing.

Manufacturing hydraulic & pneumatic equipment, machinery and control systems, mechanisms, robotics device, precision machine elements.  Inspecting and control manufacturing standards, analyzing stresses and tolerances, selecting materials, engineering computations and technical improvements, documentation, projects development, supplying.

  
Automation, Conveyors, Spiral Elevator, Fast Cannery Transportation, Electronic and Electrical Components, Master Control Center, Sheet Metal Oven Rebuilding Project. Power Systems, UPS.

Automation equipment and machine control using for machines and robotics precision mechanisms motion programming, fluid mechanics, pneumatics systems, mounting and positioning devices, electro-mechanical and vacuum mechanisms, design and analysis of structures, castings, welded frames, mechanical detailing. 

Computers: 

DOS, SUN UNIX, MAC, WP, dB, Lotus, Network, Windows & Applications; MS Project, Excel, Access, Word, PFS, Graphics, CAD / CAM, Excel, Basic, C, Fortran, Analyzes. CADD systems, Algor, VAX, Net.  MCAD, Acad's 2002 & Softdesk, Script, Nastran, Infusoft, LAN, Tektronix, Cadkey,  Lisp, Personal Designer, ACAD / Computer Instructor, Machine Design, Robotics & Automation, WIND, SOLAR, METRIC.



EDUCATION:

Institute for Business & Technology, California
CADD Engineer,  Programming,  Design,  Management


Electro - Mechanical  College
Mechanical Engineering - BSME,   ASEE,  MBA




Open for Travel  *  Salary open *  Permanent  preferred  or Consulting








From edcjones at erols.com  Sun Oct 26 08:41:10 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Sun Oct 26 08:41:10 2003
Subject: [Numpy-discussion] Buglet in NA_set... functions
Message-ID: <3F9BF835.6050903@erols.com>

The source code for NA_set_Float has a "#if HAS_UINT64" while 
NA_set_Int64 doesn't. Neither function works for UInt64 input. It seems 
that the only difference between these two functions is the cast done to 
the input variable "v" when the function is called.




From Promoteing at 2911.net  Sun Oct 26 18:52:21 2003
From: Promoteing at 2911.net (Manager)
Date: Sun Oct 26 18:52:21 2003
Subject: [Numpy-discussion] Marketing Strategy
Message-ID: <E1ADxTU-0001xM-P0@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending
out targeted emails, or want to avoid the work of sending out targeted
emails. We will do it for you!  We can send your email message to your
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Dana DeBolt
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database,
go here www.awayoutofdebtfast.com/dbtremove.htm



From yive96jf at yahoo.com  Mon Oct 27 07:33:09 2003
From: yive96jf at yahoo.com (Isaiah Champagne)
Date: Mon Oct 27 07:33:09 2003
Subject: [Numpy-discussion] INVESTORS: Blue-Chip, Stock-Trading System---77% Return---Automated...cruz
Message-ID: <7q2nx---h4$j15mw1$jowb$ipfp@b7ocg>

Investors: Come see Wall Streets only scale-trading system for blue-chip stocks - MainScale

We DO NOT TOUT INDIVIDUAL STOCKS - This is an automated, stock-trading system for blue-chips only


www.mainscale4u.com/?032335


MainScale started on October 1, 2002

Here are the results our investors have enjoyed over the last year.

Banked return, 1-year: 77.98%

12 consecutive months of profitability

Trades---467
Gainers--442
Losers----15


www.mainscale4u.com/?032335


In fact, the longest period between profitable trades was just 6 days.

In less than 15 minutes a day, you can manage a profitable portfolio that will make you money in any type of market.



www.mainscale4u.com/?032335




No more advertisements, go here: www.mainscale4u.com/nomore.html







































nw u rxdqclfmhk  g nmwznrxsd

From jmiller at stsci.edu  Mon Oct 27 07:47:36 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 27 07:47:36 2003
Subject: [Numpy-discussion] Buglet in NA_set... functions
In-Reply-To: <3F9BF835.6050903@erols.com>
References: <3F9BF835.6050903@erols.com>
Message-ID: <1067269419.1222.19.camel@halloween.stsci.edu>

On Sun, 2003-10-26 at 11:37, Edward C. Jones wrote:
> The source code for NA_set_Float has a "#if HAS_UINT64" while 
> NA_set_Int64 doesn't. Neither function works for UInt64 input. It seems 
> that the only difference between these two functions is the cast done to 
> the input variable "v" when the function is called.
> 
Currently, UInt64 is supported everywhere but under win32/MSVC.  So, on
the standard windows numarray installation,  Uint64 is not supported and
UInt64 arrays cannot be created.  Under these circumstances, the UInt64
paths you're referring to cannot be reached anyway.  Further,  since the
code in question compiles without warnings or errors,  I'd argue that it
*does* work for UInt64 inputs, although they're never going to appear. I
say this because there are indeed sections of numarray code that *don't*
compile without errors for MSVC, hence all UInt64 has been disabled for
MSVC.   Bottom line:  what you're talking about is indeed a little
inconsistent,  but  I don't think it's going to hurt us.

> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Mon Oct 27 08:04:27 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 27 08:04:27 2003
Subject: [Numpy-discussion] NA_getType needs to be documented
In-Reply-To: <3F9876D9.8040905@erols.com>
References: <3F9876D9.8040905@erols.com>
Message-ID: <1067270527.1223.39.camel@halloween.stsci.edu>

There's a mix of "interface" and "implementation" in libnumarray since
the API jump table mechanism is the only kind of inter-module linkage
used.  Since some of the functions in libnumarray are just there because
they needed to be shared within the implementation, not exported as
public interface, "everything" is never going to be documented. 
However,  specific holes that people point out certainly can be.  I'll
document this one.

Regards,
Todd

On Thu, 2003-10-23 at 20:48, Edward C. Jones wrote:
> "NA_getType" needs to be documented. The following is useful:
> 
>      if (!PyArg_ParseTuple(args, "O", &type))
>          return NULL;
> 
>      temptype = NA_getType(type);
>      if (temptype == NULL) return NULL;
>      typeno = NA_typeObjectToTypeNo(temptype);
>      Py_DECREF(temptype);
>      if (typeno < 0) {
>          PyErr_Format(PyExc_RuntimeError,
>                   "_numarray_init: can't get typeno for type");
>          return NULL;
>      }
> 
> Do other functions in "libnumarraymodule.c" need to be documented?
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From Orderlists at 2911.net  Tue Oct 28 11:22:01 2003
From: Orderlists at 2911.net (Manager)
Date: Tue Oct 28 11:22:01 2003
Subject: [Numpy-discussion] Marketing Strategy
Message-ID: <E1AEZO1-00047f-JG@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending
out targeted emails, or want to avoid the work of sending out targeted
emails. We will do it for you!  We can send your email message to your
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Dana DeBolt
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database,
go here www.awayoutofdebtfast.com/dbtremove.htm



From rob at hooft.net  Fri Oct 31 05:36:17 2003
From: rob at hooft.net (Rob W.W. Hooft)
Date: Fri Oct 31 05:36:17 2003
Subject: [Numpy-discussion] Problem in LinearAlgebra?
Message-ID: <3FA2617A.4000308@hooft.net>

I am using Polynomial.py from Scientific Python 2.1, together with 
Numeric 17.1.2. This has always served me well, but now we are busy 
upgrading our software, and I am currently porting some code to 
Scientific Python 2.4.1, Numeric 22.0. Suddenly I do no longer manage to 
get proper 2D polynomial fits over 4x4th order. At 5x5 the coefficients 
that come back from LinearAlgebra.linear_least_squares have exploded. In 
the old setup, I easily managed 9x9th order if I needed to, but most of 
the time I'd stop at 6x6th order. Would anyone have any idea how this 
difference can come about? I managed to work around this for the moment 
by using the equivalent code in the fitPolynomial routine that uses 
LinearAlgebra.generalized_inverse (and it doesn't even have problems 
with the same data at 8x8), but this definitely feels not right! I can't 
remember reading anything like this here before.

Together with Konrad Hinsen, I came to the conclusion that the problem 
is not in Scientific Python, so it must be the underlying LinearAlgebra 
code that changed between releases 17 and 22.

I hacked up a simplified example. Not sure whether it is the most simple 
case, but this resembles what I have in my code, and I'm quite sure it 
worked with Numeric 17.x, but currently it is horrible over order (4,4):

--------------------------------------
import Numeric

def func(x,y):
     return x+0.1*x**2+0.01*x**4+0.002*x**6+0.03*x*y+0.001*x**4*y**5

x=[]
y=[]
z=[]
for dx in Numeric.arange(0,1,0.01):
     for dy in Numeric.arange(0,1,0.01):
         x.append(dx)
         y.append(dy)
         z.append(func(dx,dy))

from Scientific.Functions import Polynomial
data=Numeric.transpose([x,y])
z=Numeric.array(z)
for i in range(10):
     print data[i],z[i]
pol=Polynomial.fitPolynomial((4,4),data,z)
print pol.coeff
------------------------------------
for 4,4 this prints:
[[  1.84845529e-05  -7.60502772e-13   2.71314749e-12  -3.66731796e-12
          1.66977148e-12]
  [  9.99422967e-01   3.00000000e-02  -3.26346097e-11   4.42406519e-11
         -2.01549767e-11]
  [  1.03899464e-01  -3.19668064e-11   1.14721790e-10  -1.55489826e-10
          7.08425891e-11]
  [ -9.40275000e-03   4.28456838e-11  -1.53705205e-10   2.08279772e-10
         -9.48840470e-11]
  [  1.80352695e-02  -1.10999843e-04   8.00662570e-04  -2.17266676e-03
          2.47500004e-03]]

for 5,5:

[[ -2.25705839e+03   6.69051337e+02  -6.60470163e+03   6.66572425e+03
         -8.67897022e+02   1.83974866e+03]
  [ -2.58646837e+02  -2.46554689e+03   1.15965805e+03   7.01089888e+03
         -2.11395436e+03   2.10884815e+03]
  [  3.93307499e+03   4.34484805e+02  -4.84080392e+03   5.90375330e+03
          1.16798049e+03  -4.14163933e+03]
  [  1.62814750e+03   2.08717457e+03   1.15870693e+03  -3.37838057e+03
          3.49821689e+03   5.80572585e+03]
  [  4.54127557e+02  -1.56645524e+03   4.58997025e+00   1.69772635e+03
         -1.37751039e+03  -7.59726558e+02]
  [  2.37878239e+03   9.43032094e+02   8.58518644e+02  -8.35846339e+03
         -5.55845668e+02   1.87502761e+03]]

Which is clearly wrong.

I appreciate any help!

Regards,

Rob

-- 
Rob W.W. Hooft  ||  rob at hooft.net  ||  http://www.hooft.net/people/rob/




From edcjones at erols.com  Fri Oct 31 18:16:22 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Fri Oct 31 18:16:22 2003
Subject: [Numpy-discussion] gcc compile / link questions
Message-ID: <3FA31683.10703@erols.com>

I compile and link Python extension modules using the script

gcc -fPIC -g -I/usr/local/include/python2.3 \
  -Wall -Wstrict-prototypes -c mymodule.c
g++ -shared mymodule.o -L/usr/local/lib -o mymodule.so

It works for me but it isn't pretty. Is there a better way to write it?

Gcc finds all the libraries that need to be linked in. For example,
"/usr/local/lib/python2.3/site-packages/numarray/libnumarray.so". How 
does gcc do this?

I created a .so file "utilities.so" that contains some C functions that 
are called in mymodule.c but are not visible from Python. Both 
"utilities.c" and "mymodule.c" use numarray. What changes do I make in 
the script above? Must I use the nasty "libnumarray_UNIQUE_SYMBOL" trick?

What is a script for creating "utilities.a" using gcc? How do I change 
the script above to include "utilities.a"?





From jochen at jochen-kuepper.de  Wed Oct  1 01:41:01 2003
From: jochen at jochen-kuepper.de (=?iso-8859-1?q?Jochen_K=FCpper?=)
Date: Wed Oct  1 01:41:01 2003
Subject: [Numpy-discussion] latest cvs issues
Message-ID: <86wubp9wsr.fsf@doze.rijnh.nl>

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, 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
| >>>
`----



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.)

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




From Marc.Poinot at onera.fr  Wed Oct  1 01:58:01 2003
From: Marc.Poinot at onera.fr (Marc Poinot)
Date: Wed Oct  1 01:58:01 2003
Subject: [Numpy-discussion] Migrating Char arrays
References: <3F79AD6D.12732A71@onera.fr> <200309301840.41624.falted@openlc.org>
Message-ID: <3F7A96EF.E186F638@onera.fr>

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: poinot at onera.fr
 ONERA -MFE/DSNA/ELSA    Tel: 01.46.73.42.84  Info: elsa-info at onera.fr
 29, Div. Leclerc        Fax: 01.46.73.41.66  Site:     
 92322 Chatillon FRANCE  Project: elsA        Web: http://www.onera.fr



From jmiller at stsci.edu  Wed Oct  1 03:30:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct  1 03:30:04 2003
Subject: [Numpy-discussion] latest cvs issues
In-Reply-To: <86wubp9wsr.fsf@doze.rijnh.nl>
References: <86wubp9wsr.fsf@doze.rijnh.nl>
Message-ID: <1065004124.3460.62.camel@localhost.localdomain>

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 <jmiller at stsci.edu>




From falted at openlc.org  Wed Oct  1 03:39:13 2003
From: falted at openlc.org (Francesc Alted)
Date: Wed Oct  1 03:39:13 2003
Subject: [Numpy-discussion] Migrating Char arrays
In-Reply-To: <3F7A96EF.E186F638@onera.fr>
References: <3F79AD6D.12732A71@onera.fr> <200309301840.41624.falted@openlc.org> <3F7A96EF.E186F638@onera.fr>
Message-ID: <200310011238.17409.falted@openlc.org>

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




From jochen at jochen-kuepper.de  Wed Oct  1 04:57:01 2003
From: jochen at jochen-kuepper.de (=?iso-8859-1?q?Jochen_K=FCpper?=)
Date: Wed Oct  1 04:57:01 2003
Subject: [Numpy-discussion] latest cvs issues
In-Reply-To: <1065004124.3460.62.camel@localhost.localdomain> (Todd Miller's
 message of "01 Oct 2003 06:28:45 -0400")
References: <86wubp9wsr.fsf@doze.rijnh.nl>
	<1065004124.3460.62.camel@localhost.localdomain>
Message-ID: <86y8w5895e.fsf@doze.rijnh.nl>

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

Todd> On Wed, 2003-10-01 at 04:39, Jochen K?pper 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: 

[The problem was '-march=pentium4'.]

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
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Libert?, ?galit?, Fraternit?                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)




From jmiller at stsci.edu  Wed Oct  1 06:06:05 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct  1 06:06:05 2003
Subject: [Numpy-discussion] latest cvs issues
In-Reply-To: <86y8w5895e.fsf@doze.rijnh.nl>
References: <86wubp9wsr.fsf@doze.rijnh.nl>
	<1065004124.3460.62.camel@localhost.localdomain> 
	<86y8w5895e.fsf@doze.rijnh.nl>
Message-ID: <1065013512.17541.1.camel@halloween.stsci.edu>

On Wed, 2003-10-01 at 07:55, Jochen K?pper wrote:
> On 01 Oct 2003 06:28:45 -0400 Todd Miller wrote:
> 
> Todd> On Wed, 2003-10-01 at 04:39, Jochen K?pper 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?:)
> 
Done.

-- 
Todd Miller 			jmiller at stsci.edu
STSCI / ESS / SSB




From jochen at jochen-kuepper.de  Wed Oct  1 10:35:10 2003
From: jochen at jochen-kuepper.de (=?iso-8859-1?q?Jochen_K=FCpper?=)
Date: Wed Oct  1 10:35:10 2003
Subject: [Numpy-discussion] compilation issues
In-Reply-To: <86wubp9wsr.fsf@doze.rijnh.nl> (Jochen
 =?iso-8859-1?q?K=FCpper's?= message of "Wed, 01 Oct 2003 10:39:16 +0200")
References: <86wubp9wsr.fsf@doze.rijnh.nl>
Message-ID: <868yo4982w.fsf@doze.rijnh.nl>

On Wed, 01 Oct 2003 10:39:16 +0200 Jochen K?pper wrote:

Jochen> Moreover I have a compilation issue which is probably a gcc bug, but
Jochen> here we go: 
Jochen> ,----
Jochen> | > 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
Jochen> | Src/_ufuncComplex32module.c: In function `multiply_Complex32_reduce':
Jochen> | Src/_ufuncComplex32module.c:401: unable to find a register to spill 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, bailing out
Jochen> `----

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

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




From cjw at sympatico.ca  Wed Oct  1 14:45:06 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Wed Oct  1 14:45:06 2003
Subject: [Numpy-discussion] Small integers not promoted for calculations
Message-ID: <3F7B4AAE.3000409@sympatico.ca>

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
 >>>




From jmiller at stsci.edu  Wed Oct  1 16:03:06 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct  1 16:03:06 2003
Subject: [Numpy-discussion] Small integers not promoted for calculations
In-Reply-To: <3F7B4AAE.3000409@sympatico.ca>
References: <3F7B4AAE.3000409@sympatico.ca>
Message-ID: <1065049341.1530.20.camel@halloween.stsci.edu>

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 			jmiller at stsci.edu
STSCI / ESS / SSB




From cxsfbe46 at yahoo.com  Thu Oct  2 14:11:03 2003
From: cxsfbe46 at yahoo.com (Heidi Calhoun)
Date: Thu Oct  2 14:11:03 2003
Subject: [Numpy-discussion] Rx - VICODIN is HERE, Valium, Xanaxx, Viaegra...FAST DELIVERY............. ikrtppyuasy
Message-ID: <8pd8cj62p5g1tndto-007xfsxoyuj06@49e28ygbo.df>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031002/713076f2/attachment-0001.html>

From jean.moser at wanadoo.fr  Fri Oct  3 01:33:02 2003
From: jean.moser at wanadoo.fr (jean.moser)
Date: Fri Oct  3 01:33:02 2003
Subject: [Numpy-discussion] Problem of downloading Numeric 22.0 win 32 py 2.2 exe
Message-ID: <001001c38989$3e9ce3a0$0ef2f9c1@pc1>

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 
    kernel module 32-py 2.3 exe"

Can you help me ?

Jean
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031003/2c54cf2c/attachment-0001.html>

From rh4170056 at juno.com  Mon Oct  6 03:22:08 2003
From: rh4170056 at juno.com (rh4170056 at juno.com)
Date: Mon Oct  6 03:22:08 2003
Subject: [Numpy-discussion] What PNRG does RandomArray Use?
Message-ID: <20031006.032041.3638.91551@webmail14.lax.untd.com>

I am starting to use RandomArray for statistical simulations requiring large samples with random behavior.  Does anyone know what PNRG algorithm is used by Numeric's RandomArray module?  Have searched this and other user groups, plus NumericPython site and can't find this info.  Starting with 2.3 the regular Python random module uses Mersenne Twister which is ideal, but if I use that it slows things down considerably (because need to iterate and put the random numbers in an array before I can do ufunc operations).  Mersenne Twister has a period > 2**10,000 and behaves very "randomly".  Does RandomArray use one of similar quality?  Thanks for any information or help.

________________________________________________________________
The best thing to hit the internet in years - Juno SpeedBand!
Surf the web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!



From Norman.Shelley at motorola.com  Tue Oct  7 08:59:05 2003
From: Norman.Shelley at motorola.com (Norman Shelley)
Date: Tue Oct  7 08:59:05 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
Message-ID: <3F82E2B4.E028E764@motorola.com>

How do I take data from a double array or a complex array as defined below and
initialize a Numeric array and load it appropriately?



struct complex {
  double real;
  double imag;
} complex;

complex cdata[100];
double *data[100];
PyArrayObject *array;

/* code where cdata and data are loaded up is not included *.


I think this is how I do it for doubles (correct me if I'm wrong).
  array = PyArray_FromDims(1, numData, PyArray_DOUBLE)
  for (i=0; i< 100; i++) {
      (double *)(array->data)[i] = data[i];
  }


How do I load the data in cdata into an PyArrayObject?


Thanks,
Norman Shelley








From falted at openlc.org  Tue Oct  7 09:19:10 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct  7 09:19:10 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
In-Reply-To: <3F82E2B4.E028E764@motorola.com>
References: <3F82E2B4.E028E764@motorola.com>
Message-ID: <200310071817.55484.falted@openlc.org>

A Dimarts 07 Octubre 2003 17:58, Norman Shelley va escriure:
> How do I take data from a double array or a complex array as defined below
> and initialize a Numeric array and load it appropriately?
>
> struct complex {
>   double real;
>   double imag;
> } complex;
>
> complex cdata[100];
> double *data[100];
> PyArrayObject *array;

By reading the manual (page 65), I guess the best would be something like:

  arr = PyArray_FromDimsAndData(1, 100, PyArray_CDOUBLE, cdata)

Cheers,

-- 
Francesc Alted




From Norman.Shelley at motorola.com  Tue Oct  7 09:26:13 2003
From: Norman.Shelley at motorola.com (Norman Shelley)
Date: Tue Oct  7 09:26:13 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
References: <3F82E2B4.E028E764@motorola.com> <200310071817.55484.falted@openlc.org>
Message-ID: <3F82E8C2.5908AD70@motorola.com>

Francesc Alted wrote:

> A Dimarts 07 Octubre 2003 17:58, Norman Shelley va escriure:
> > How do I take data from a double array or a complex array as defined below
> > and initialize a Numeric array and load it appropriately?
> >
> > struct complex {
> >   double real;
> >   double imag;
> > } complex;
> >
> > complex cdata[100];
> > double *data[100];
> > PyArrayObject *array;
>
> By reading the manual (page 65), I guess the best would be something like:
>
>   arr = PyArray_FromDimsAndData(1, 100, PyArray_CDOUBLE, cdata)

If cdata is never to be freed, e.g. a Fortran COMMON block, then that is the
case.
I with to use PyArray_FromDims() and then load it up with data

I am assuming this may work for doubles (?)
aPyArrayObject = PyArray_FromDims(1, numData, PyArray_DOUBLE)
for (i = 0; i < numData; i++) aPyArrayObject.data[i] = doubledata[i];

But then I wondered how to load for COMPLEX?


>
>
> Cheers,
>
> --
> Francesc Alted




From falted at openlc.org  Tue Oct  7 10:00:13 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct  7 10:00:13 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
In-Reply-To: <3F82E8C2.5908AD70@motorola.com>
References: <3F82E2B4.E028E764@motorola.com> <200310071817.55484.falted@openlc.org> <3F82E8C2.5908AD70@motorola.com>
Message-ID: <200310071858.47432.falted@openlc.org>

A Dimarts 07 Octubre 2003 18:24, Norman Shelley va escriure:
>
> If cdata is never to be freed, e.g. a Fortran COMMON block, then that is
> the case.
> I with to use PyArray_FromDims() and then load it up with data
>
> I am assuming this may work for doubles (?)
> aPyArrayObject = PyArray_FromDims(1, numData, PyArray_DOUBLE)
> for (i = 0; i < numData; i++) aPyArrayObject.data[i] = doubledata[i];
>
> But then I wondered how to load for COMPLEX?

Perhaps something like:

  struct complex {
    double real;
    double imag;
  } complex;
  complex cdata[100];
  double *data;
  PyArrayObject *array;
  
  array = PyArray_FromDims(1, numData, PyArray_CDOUBLE)
  data = array->data
  for (i = 0; i < numData; i++) {
    *data++ = cdata[i++];
    *data++ = cdata[i];
    }
    
should work (but not tested here). CDOUBLE means double precision complex.

Something similar would work for double precision:

  complex ddata[100];
  double *data;
  PyArrayObject *array;
  
  array = PyArray_FromDims(1, numData, PyArray_DOUBLE)
  data = array->data
  for (i = 0; i < numData; i++) {
    *data++ = cdata[i];
    }

-- 
Francesc Alted




From falted at openlc.org  Tue Oct  7 10:09:05 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct  7 10:09:05 2003
Subject: [Numpy-discussion] ?Loading double and cdouble in an PyArrayObject?
In-Reply-To: <200310071858.47432.falted@openlc.org>
References: <3F82E2B4.E028E764@motorola.com> <3F82E8C2.5908AD70@motorola.com> <200310071858.47432.falted@openlc.org>
Message-ID: <200310071907.56633.falted@openlc.org>

A Dimarts 07 Octubre 2003 18:58, Francesc Alted va escriure:
Ooops, I realized that I've made an error (at least ;-)

>   data = array->data

should changed by

    data = (double *)array->data

-- 
Francesc Alted




From 076ebxvg at yahoo.com  Wed Oct  8 18:29:05 2003
From: 076ebxvg at yahoo.com (Garth Whitfield)
Date: Wed Oct  8 18:29:05 2003
Subject: [Numpy-discussion] INVESTORS: TRHL - Last Pick From $.45 to $1.18.......... zyvc  svupng
Message-ID: <y90t0732wo3048e081530pqq9@spam0.ljx2g>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031008/365cead4/attachment-0001.html>

From haase at msg.ucsf.edu  Thu Oct  9 10:26:10 2003
From: haase at msg.ucsf.edu (Sebastian Haase)
Date: Thu Oct  9 10:26:10 2003
Subject: [Numpy-discussion] numarray bug !? astype with 2d array gives transform ??
Message-ID: <077701c38e8a$5e191900$421ee6a9@rodan>

Hi !
I just discovered this: (I'm using numarray 0.6 [on windows])

>>> dy = na.fromfunction(lambda y,x: y, (3,3))
>>> dx = na.fromfunction(lambda y,x: x, (3,3))
>>> dy
array([[0, 0, 0],
       [1, 1, 1],
       [2, 2, 2]])
>>> dx
array([[0, 1, 2],
       [0, 1, 2],
       [0, 1, 2]])
>>> dx.type()
Int32
>>> dx.astype(na.Int8)
array([[0, 0, 0],
       [1, 1, 1],
       [2, 2, 2]], type=Int8)
>>> dx.astype(na.Int16)
array([[0, 0, 0],
       [1, 1, 1],
       [2, 2, 2]], type=Int16)
>>> dx.astype(na.Float)
array([[ 0.,  0.,  0.],
       [ 1.,  1.,  1.],
       [ 2.,  2.,  2.]])
>>> dx.astype(na.Float32)
array([[ 0.,  0.,  0.],
       [ 1.,  1.,  1.],
       [ 2.,  2.,  2.]], type=Float32)

What does this mean ? Am I missing something ?

Thanks,
Sebastian Haase




From jmiller at stsci.edu  Fri Oct 10 07:19:12 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Fri Oct 10 07:19:12 2003
Subject: [Numpy-discussion] doctest fortran I/O synchronization
Message-ID: <1065795474.24316.105.camel@halloween.stsci.edu>

I'm trying to make a doctest to verify that the different flow patterns
of f2py interfaces work with different varieties of numarrays (normal,
byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
to test this out under Linux with g77, and (it seems like) I'm having
trouble synchronizing the Fortran I/O with Python's C I/O.

Given foo.f:

      subroutine in_c(a,m,n)
      real*8 a(n,m)
Cf2py intent(in,c) a
Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
      do j=1,m
         do i=1,n
            write (6,1) a(i,j)
 1          format( $, 1F3.0, ', ')
         enddo
         print *,''
      enddo
      end

And given f2py_tests.py:

"""
>>> foo.in_f(a)
 0.,  5., 10.,
 1.,  6., 11.,
 2.,  7., 12.,
 3.,  8., 13.,
 4.,  9., 14.,
"""
import foo, numarray

def test():
    import doctest
    global a
    t = doctest.Tester(globs=globals())
    a = numarray.arange(15., shape=(3,5))
    t.runstring(__doc__, "c_array")
    return t.summarize()

I get this:

[jmiller at halloween ~/f2py_tests]$ python f2py_tests.py
 0.,  5., 10.,
 1.,  6., 11.,
 2.,  7., 12.,
 3.,  8., 13.,
 4.,  9., 14.,
*****************************************************************
Failure in example: foo.in_f(a)
from line #1 of c_array
Expected:
 0.,  5., 10.,
 1.,  6., 11.,
 2.,  7., 12.,
 3.,  8., 13.,
 4.,  9., 14.,
Got:
*****************************************************************
1 items had failures:
   1 of   1 in c_array
***Test Failed*** 1 failures.

Where it appears that the output from the first example somehow escapes
the C I/O system I presume doctest is using.  The actual test I'm
writing has multiple examples, and the fortran I/O *does* make it into
the doctest after the first example  but remains out of sync.

Does anyone have an explanation and/or fix for this problem?

-- 
Todd Miller 			jmiller at stsci.edu
STSCI / ESS / SSB




From pearu at scipy.org  Fri Oct 10 07:54:07 2003
From: pearu at scipy.org (Pearu Peterson)
Date: Fri Oct 10 07:54:07 2003
Subject: [Numpy-discussion] Re: [SciPy-user] doctest fortran I/O synchronization
In-Reply-To: <1065795474.24316.105.camel@halloween.stsci.edu>
Message-ID: <Pine.LNX.4.44.0310100937020.6282-100000@scipy.org>

Hi Todd,

On 10 Oct 2003, Todd Miller wrote:

> I'm trying to make a doctest to verify that the different flow patterns
> of f2py interfaces work with different varieties of numarrays (normal,
> byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
> to test this out under Linux with g77, and (it seems like) I'm having
> trouble synchronizing the Fortran I/O with Python's C I/O.
> 
> Given foo.f:
> 
>       subroutine in_c(a,m,n)
>       real*8 a(n,m)
> Cf2py intent(in,c) a
> Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
>       do j=1,m
>          do i=1,n
>             write (6,1) a(i,j)
>  1          format( $, 1F3.0, ', ')
>          enddo
>          print *,''
>       enddo
>       end
> 
> And given f2py_tests.py:

> """
> >>> foo.in_f(a)
<snip>

I could not run given tests as they were not complete and had typos.
For instance, foo.f defines in_c but in test string you are using in_f.
Also AFAIK, Python I/O will not catch I/O from Fortran.

Any way, when I modify in_c to in_f then the following code

  a = numarray.arange(15., shape=(3,5))
  print a
  foo.in_f(a)

outputs:

[[  0.   1.   2.   3.   4.]
 [  5.   6.   7.   8.   9.]
 [ 10.  11.  12.  13.  14.]]
 0.,  1.,  2.,  
 3.,  4.,  5.,  
 6.,  7.,  8.,  
 9., 10., 11.,  
12., 13., 14.,  

You probaly would not expect this. This is related to different storage 
order in C and Fortran, of cource, and you have disabled f2py ability to 
take into account this by using intent(c).

So, when you would not use intent(c), that is, in foo.f is a line

  Cf2py intent(in) a

then the following output occurs:

[[  0.   1.   2.   3.   4.]
 [  5.   6.   7.   8.   9.]
 [ 10.  11.  12.  13.  14.]]
 0.,  5., 10.,  
 1.,  6., 11.,  
 2.,  7., 12.,  
 3.,  8., 13.,  
 4.,  9., 14.,  

The arrays look transposed because in Fortran your row index varies 
faster, that is, a transposed array is displayed.

To sum up, don't use intent(c) and change the order of loops in in_f 
function to get matching results.

HTH,
  Pearu




From cookedm at physics.mcmaster.ca  Fri Oct 10 09:40:05 2003
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Fri Oct 10 09:40:05 2003
Subject: [Numpy-discussion] doctest fortran I/O synchronization
In-Reply-To: <1065795474.24316.105.camel@halloween.stsci.edu>
References: <1065795474.24316.105.camel@halloween.stsci.edu>
Message-ID: <20031010163743.GA19086@arbutus.physics.mcmaster.ca>

On Fri, Oct 10, 2003 at 10:17:54AM -0400, Todd Miller wrote:
> I'm trying to make a doctest to verify that the different flow patterns
> of f2py interfaces work with different varieties of numarrays (normal,
> byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
> to test this out under Linux with g77, and (it seems like) I'm having
> trouble synchronizing the Fortran I/O with Python's C I/O.
> 
> Given foo.f:
> 
>       subroutine in_c(a,m,n)
>       real*8 a(n,m)
> Cf2py intent(in,c) a
> Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
>       do j=1,m
>          do i=1,n
>             write (6,1) a(i,j)
>  1          format( $, 1F3.0, ', ')
>          enddo
>          print *,''
>       enddo
>       end
> 
> And given f2py_tests.py:
> 
> """
> >>> foo.in_f(a)
>  0.,  5., 10.,
>  1.,  6., 11.,
>  2.,  7., 12.,
>  3.,  8., 13.,
>  4.,  9., 14.,
> """
> import foo, numarray
> 
> def test():
>     import doctest
>     global a
>     t = doctest.Tester(globs=globals())
>     a = numarray.arange(15., shape=(3,5))
>     t.runstring(__doc__, "c_array")
>     return t.summarize()
> 
> I get this:
> 
> [jmiller at halloween ~/f2py_tests]$ python f2py_tests.py
>  0.,  5., 10.,
>  1.,  6., 11.,
>  2.,  7., 12.,
>  3.,  8., 13.,
>  4.,  9., 14.,
> *****************************************************************
> Failure in example: foo.in_f(a)
> from line #1 of c_array
> Expected:
>  0.,  5., 10.,
>  1.,  6., 11.,
>  2.,  7., 12.,
>  3.,  8., 13.,
>  4.,  9., 14.,
> Got:
> *****************************************************************
> 1 items had failures:
>    1 of   1 in c_array
> ***Test Failed*** 1 failures.
> 
> Where it appears that the output from the first example somehow escapes
> the C I/O system I presume doctest is using.  The actual test I'm

doctest uses Python's I/O system: it assigns a new object to
sys.stdout. Your code uses Fortran's output, which would go the same
place a printf in C would: to the program's stdout (file descriptor 1).

You'd need to run the code in a separate process, and capture the
output. Something along the lines of this:

import commands
def test_f2py():
    """
    put your doctest here
    """
    output = commands.getoutput('python f2pytest1.py')
    print output

Or, set your test up to write output to a file instead of stdout, then
read that file (that's probably better).

> writing has multiple examples, and the fortran I/O *does* make it into
> the doctest after the first example  but remains out of sync.

It's out of sync because it's not going through Python; Python has
absolutely no clue that the Fortran code wrote anything.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca



From jmiller at stsci.edu  Fri Oct 10 10:23:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Fri Oct 10 10:23:04 2003
Subject: [Numpy-discussion] doctest fortran I/O synchronization
In-Reply-To: <20031010163743.GA19086@arbutus.physics.mcmaster.ca>
References: <1065795474.24316.105.camel@halloween.stsci.edu> 
	<20031010163743.GA19086@arbutus.physics.mcmaster.ca>
Message-ID: <1065806510.24315.197.camel@halloween.stsci.edu>

Thanks for the work around.  I haven't tried it yet but I've got a
feeling I'm home free...  something along these lines will definitely
work.

Regards,
Todd

On Fri, 2003-10-10 at 12:37, David M. Cooke wrote:
> On Fri, Oct 10, 2003 at 10:17:54AM -0400, Todd Miller wrote:
> > I'm trying to make a doctest to verify that the different flow patterns
> > of f2py interfaces work with different varieties of numarrays (normal,
> > byte-swapped, misaligned, dis-contiguous, type-converted).  I'm trying
> > to test this out under Linux with g77, and (it seems like) I'm having
> > trouble synchronizing the Fortran I/O with Python's C I/O.
> > 
> > Given foo.f:
> > 
> >       subroutine in_c(a,m,n)
> >       real*8 a(n,m)
> > Cf2py intent(in,c) a
> > Cf2py depend(a) ::  n=shape(a,0),  m=shape(a,1)
> >       do j=1,m
> >          do i=1,n
> >             write (6,1) a(i,j)
> >  1          format( $, 1F3.0, ', ')
> >          enddo
> >          print *,''
> >       enddo
> >       end
> > 
> > And given f2py_tests.py:
> > 
> > """
> > >>> foo.in_f(a)
> >  0.,  5., 10.,
> >  1.,  6., 11.,
> >  2.,  7., 12.,
> >  3.,  8., 13.,
> >  4.,  9., 14.,
> > """
> > import foo, numarray
> > 
> > def test():
> >     import doctest
> >     global a
> >     t = doctest.Tester(globs=globals())
> >     a = numarray.arange(15., shape=(3,5))
> >     t.runstring(__doc__, "c_array")
> >     return t.summarize()
> > 
> > I get this:
> > 
> > [jmiller at halloween ~/f2py_tests]$ python f2py_tests.py
> >  0.,  5., 10.,
> >  1.,  6., 11.,
> >  2.,  7., 12.,
> >  3.,  8., 13.,
> >  4.,  9., 14.,
> > *****************************************************************
> > Failure in example: foo.in_f(a)
> > from line #1 of c_array
> > Expected:
> >  0.,  5., 10.,
> >  1.,  6., 11.,
> >  2.,  7., 12.,
> >  3.,  8., 13.,
> >  4.,  9., 14.,
> > Got:
> > *****************************************************************
> > 1 items had failures:
> >    1 of   1 in c_array
> > ***Test Failed*** 1 failures.
> > 
> > Where it appears that the output from the first example somehow escapes
> > the C I/O system I presume doctest is using.  The actual test I'm
> 
> doctest uses Python's I/O system: it assigns a new object to
> sys.stdout. Your code uses Fortran's output, which would go the same
> place a printf in C would: to the program's stdout (file descriptor 1).
> 
> You'd need to run the code in a separate process, and capture the
> output. Something along the lines of this:
> 
> import commands
> def test_f2py():
>     """
>     put your doctest here
>     """
>     output = commands.getoutput('python f2pytest1.py')
>     print output
> 
> Or, set your test up to write output to a file instead of stdout, then
> read that file (that's probably better).
> 
> > writing has multiple examples, and the fortran I/O *does* make it into
> > the doctest after the first example  but remains out of sync.
> 
> It's out of sync because it's not going through Python; Python has
> absolutely no clue that the Fortran code wrote anything.
> 
> -- 
> |>|\/|<
> /--------------------------------------------------------------------------\
> |David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
> |cookedm at physics.mcmaster.ca
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			jmiller at stsci.edu
STSCI / ESS / SSB




From bce40yvg at yahoo.com  Sat Oct 11 05:19:03 2003
From: bce40yvg at yahoo.com (Gay Lang)
Date: Sat Oct 11 05:19:03 2003
Subject: [Numpy-discussion] <b><font size="5">Rx Outlet</font></b><p>Vicodon on sale for a limited time. <br> e tegdedcrp
Message-ID: <683614s7744ui$4v35c2mpdeuh33x185@txvw.dn>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031011/fdcfb6eb/attachment-0001.html>

From mcebkbb at yahoo.com  Sun Oct 12 12:57:02 2003
From: mcebkbb at yahoo.com (Teresa Rodgers)
Date: Sun Oct 12 12:57:02 2003
Subject: [Numpy-discussion] Rx: VICODIN is Here - Just Pennies per Tablet.................. gq v v
Message-ID: <669lfd6f78ndd049@6fo.8p9me>

Academic Qualifications available from prestigious NON?ACCREDITTED universities.

Do you have the knowledge and the experience but lack the qualifications?

Are you getting turned down time and time again for the job of your dreams because you just don't have the right letters after your name?

Get the prestige that you deserve today!

Move ahead in your career today!

Bachelors, Masters and PhD's available in your field!

No examinations! No classes! No textbooks!


Call to register and receive your qualifications within days!

24 hours a day 7 days a week!

Confidentiality assured!


203-286-2187 - USA

44-207-681-2635 - INTERNATIONAL





















vuuoakogiurnwjtfgwnf eq a hcf 
bgbfwjmu ocuetarzjziv xmpxa xdyqn ffr f pl
my
wklw qhpspa

From haase at msg.ucsf.edu  Mon Oct 13 09:12:03 2003
From: haase at msg.ucsf.edu (Sebastian Haase)
Date: Mon Oct 13 09:12:03 2003
Subject: [Numpy-discussion] numarray bug !? astype with 2d array gives transform ??
References: <077701c38e8a$5e191900$421ee6a9@rodan>
Message-ID: <091201c391a4$9dfb9300$421ee6a9@rodan>

Hi all,
Could someone maybe confirm this or say that numarray 0.7 has fixed this ?
I also found more problems when type conversions are involved:  I had a 3d
stack of UInt16  data and wanted to compute the 2d-fft of different
sections -> I got identical ffts for different sections ;-(

Please help,
Sebastian Haase

----- Original Message ----- 
From: "Sebastian Haase" <haase at msg.ucsf.edu>
To: <numpy-discussion at lists.sourceforge.net>
Sent: Thursday, October 09, 2003 10:25 AM
Subject: [Numpy-discussion] numarray bug !? astype with 2d array gives
transform ??


> Hi !
> I just discovered this: (I'm using numarray 0.6 [on windows])
>
> >>> dy = na.fromfunction(lambda y,x: y, (3,3))
> >>> dx = na.fromfunction(lambda y,x: x, (3,3))
> >>> dy
> array([[0, 0, 0],
>        [1, 1, 1],
>        [2, 2, 2]])
> >>> dx
> array([[0, 1, 2],
>        [0, 1, 2],
>        [0, 1, 2]])
> >>> dx.type()
> Int32
> >>> dx.astype(na.Int8)
> array([[0, 0, 0],
>        [1, 1, 1],
>        [2, 2, 2]], type=Int8)
> >>> dx.astype(na.Int16)
> array([[0, 0, 0],
>        [1, 1, 1],
>        [2, 2, 2]], type=Int16)
> >>> dx.astype(na.Float)
> array([[ 0.,  0.,  0.],
>        [ 1.,  1.,  1.],
>        [ 2.,  2.,  2.]])
> >>> dx.astype(na.Float32)
> array([[ 0.,  0.,  0.],
>        [ 1.,  1.,  1.],
>        [ 2.,  2.,  2.]], type=Float32)
>
> What does this mean ? Am I missing something ?
>
> Thanks,
> Sebastian Haase
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>




From hvgbyz at yahoo.com  Mon Oct 13 21:45:06 2003
From: hvgbyz at yahoo.com (Laverne Mccarthy)
Date: Mon Oct 13 21:45:06 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... x
Message-ID: <y7d$094-3xtqj87-$$56-vjr2@sp8.hgn0o9>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031013/849a229c/attachment-0001.html>

From jh327xwsqx at yahoo.com  Mon Oct 13 23:24:02 2003
From: jh327xwsqx at yahoo.com (Jeremiah Riley)
Date: Mon Oct 13 23:24:02 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... mtfppq y
Message-ID: <908y95a70o8k8juy627jbov@uww6.ffioe>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031013/bb021c09/attachment-0001.html>

From haase at msg.ucsf.edu  Tue Oct 14 09:26:07 2003
From: haase at msg.ucsf.edu (Sebastian Haase)
Date: Tue Oct 14 09:26:07 2003
Subject: [Numpy-discussion] numarray bug !? astype with 2d array givestransform ??
References: <077701c38e8a$5e191900$421ee6a9@rodan> <091201c391a4$9dfb9300$421ee6a9@rodan> <1066129129.7669.0.camel@Nadav.Envision.co.il>
Message-ID: <09cd01c3926f$ce1da3e0$421ee6a9@rodan>


From oc6cclwdr at yahoo.com  Wed Oct 15 01:39:05 2003
From: oc6cclwdr at yahoo.com (Jeffery Tompkins)
Date: Wed Oct 15 01:39:05 2003
Subject: [Numpy-discussion] NEW STOCK PICK: TRHL - Last Pick From $.45 to $1.18.......... t wbpjqe  ssp
Message-ID: <130h305o13re640517g7218@fxbxh>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/3121d3cd/attachment-0001.html>

From jzqxufemce at yahoo.com  Wed Oct 15 01:40:06 2003
From: jzqxufemce at yahoo.com (Michael Rasmussen)
Date: Wed Oct 15 01:40:06 2003
Subject: [Numpy-discussion] NEW STOCK PICK: TRHL - Last Pick From $.45 to $1.18.......... vvxk cnkaqv kqec
Message-ID: <0fd7q6gj9881j6ph7x2t2886mn$o2hs@mv5.3b>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/f5951c1d/attachment-0001.html>

From 31kgbvd at yahoo.com  Wed Oct 15 01:40:07 2003
From: 31kgbvd at yahoo.com (Hollie Ramey)
Date: Wed Oct 15 01:40:07 2003
Subject: [Numpy-discussion] NEW STOCK PICK: TRHL - Last Pick From $.45 to $1.18.......... dwowss jtg
Message-ID: <uk2846s7w8v9cl86bh53h@js8.u.9y31kfmz>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/bca71131/attachment-0001.html>

From lqmkfkh168 at yahoo.com  Wed Oct 15 08:25:06 2003
From: lqmkfkh168 at yahoo.com (Reynaldo Webb)
Date: Wed Oct 15 08:25:06 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... njf git
Message-ID: <e14b1vy81uk299b71t612r9592v@2v6yf.kf2qq>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/fc372750/attachment-0001.html>

From d9eekaov at yahoo.com  Wed Oct 15 08:35:02 2003
From: d9eekaov at yahoo.com (Theron Cameron)
Date: Wed Oct 15 08:35:02 2003
Subject: [Numpy-discussion] INVESTORS: TRHL - U.S. STOCK MARKET - Last Pick From $.45 to $1.18.......... uqh pq uvyrmxiyl
Message-ID: <bey4n2l1m6d9h0o0drq$e37g02x2o60@4w2.g.96f1rr6>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/a9b29ed2/attachment-0001.html>

From j4cgsag at yahoo.com  Wed Oct 15 10:09:01 2003
From: j4cgsag at yahoo.com (Mac Mercer)
Date: Wed Oct 15 10:09:01 2003
Subject: [Numpy-discussion] PROTECT YOUR CHILDREN From Offensive Language On Your TV With ProtecTV................... m mdyxfemjuu ml
Message-ID: <xmio1b1481028uu$30u0@np5.tje9j5sl8v>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031015/2d3ee6bf/attachment-0001.html>

From falted at openlc.org  Thu Oct 16 05:06:20 2003
From: falted at openlc.org (Francesc Alted)
Date: Thu Oct 16 05:06:20 2003
Subject: [Numpy-discussion] How to access to the start of a mmaped numarray object?
Message-ID: <200310161312.01994.falted@openlc.org>

Hi,

While dealing with memory mapped numarray objects, I'm having some problems
to access to the address where the data starts. For normal (i.e. no
memory-mapped) objects, I normally used this:

    PyObject_AsReadBuffer(recarr._data, &self.rbuf, &buflen)

that works fine, but after creating a RecArray associated to a memory mapped
file in the normal way, i.e.:

    self.mmfile = memmap.Memmap("prova.out",mode="r")
    recarr = records.RecArray(self.mmfile[:],
                              formats=self.description._v_recarrfmt,
                              shape=self.totalrecords)

then, I'm unable to use the PyObject_AsWriteBuffer anymore. I've tried the
following:

    PyObject_AsReadBuffer(recarr._data, &self.mmrbuf, &buflen)
    (this returns a -1, failed, value)
    
    PyObject_AsReadBuffer(recarr._data._buffer, &self.mmrbuf, &buflen)
    (this produces a segmentation fault)

    PyObject_AsReadBuffer(recarr._data.__buffer__(), &self.mmrbuf, &buflen)
    (another seg fault)

Of course, I've checked out that the recarr object is sane (i.e. it has the
same data than the file). Any hint?

-- 
Francesc Alted




From falted at openlc.org  Thu Oct 16 06:00:01 2003
From: falted at openlc.org (Francesc Alted)
Date: Thu Oct 16 06:00:01 2003
Subject: [Numpy-discussion] How to access to the start of a mmaped numarray object?
In-Reply-To: <200310161312.01994.falted@openlc.org>
References: <200310161312.01994.falted@openlc.org>
Message-ID: <200310161458.21714.falted@openlc.org>

A Dijous 16 Octubre 2003 13:12, Francesc Alted va escriure:
>     PyObject_AsReadBuffer(recarr._data._buffer, &self.mmrbuf, &buflen)
>     (this produces a segmentation fault)
>
>     PyObject_AsReadBuffer(recarr._data.__buffer__(), &self.mmrbuf, &buflen)
>     (another seg fault)

Ooops, sorry, the segmentation fault was taking place *after* that statement.
This code seems to work well. Anyways.

-- 
Francesc Alted




From jmiller at stsci.edu  Fri Oct 17 05:51:05 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Fri Oct 17 05:51:05 2003
Subject: [Numpy-discussion] numpy welcomes Peter Verveer as a new developer
Message-ID: <1066395037.3459.183.camel@localhost.localdomain>

By vote of the existing numpy developers, Peter Verveer has been added
to the project as a developer.  Peter has been working on a
multi-dimensional image processing package soon to be called
numarray.nd_image.  This is a great day for numarray and numpy!

Welcome Peter.

Todd

-- 
Todd Miller <jmiller at stsci.edu>




From 533ryjx at yahoo.com  Sat Oct 18 08:18:01 2003
From: 533ryjx at yahoo.com (Branden Figueroa)
Date: Sat Oct 18 08:18:01 2003
Subject: [Numpy-discussion] CASINO Online: Get $1000 Just to Play - Win a FERRARI.................. dqvhhppm zkkqbcwmc
Message-ID: <t8p988kl-4vf33f2@53a.7t.x.9b8u>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031018/a801252a/attachment-0001.html>

From edcjones at erols.com  Sun Oct 19 02:22:02 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Sun Oct 19 02:22:02 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <3F91BC37.7060200@erols.com>

#! /usr/bin/env python

# Python 2.3.2, numarray 0.7
import numarray

def fun1(code, scale):
     arr1 = numarray.ones((4,4), code)
     arr2 = scale * arr1
     arr3 = numarray.ones((4,4), code)
     # Bug appears at second multiply.
     arr4 = scale * arr3

def fun2(code, scale):
     arr = numarray.ones((4,4), code)
     arr2 = scale * arr
     # Bug appears at second multiply.
     arr3 = scale * arr

# These calls fail when "scale" is too big for "code":

#   File 
"/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
653, in __rmul__
#    def __rmul__(self, operand): return ufunc.multiply(operand, self)
# ValueError: invalid shape tuple

#fun2('Int16', 100000)
fun2('UInt8' , -1)




From jmiller at stsci.edu  Sun Oct 19 07:20:02 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Sun Oct 19 07:20:02 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <3F91BC37.7060200@erols.com>
References: <3F91BC37.7060200@erols.com>
Message-ID: <1066564851.3463.3.camel@localhost.localdomain>

I confirmed this and logged it on Source Forge as numpy-Numarray
Bugs-826311 [Numpy-discussion] Possible bug in scalar * array.

I don't have a fix yet.

Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun1(code, scale):
>      arr1 = numarray.ones((4,4), code)
>      arr2 = scale * arr1
>      arr3 = numarray.ones((4,4), code)
>      # Bug appears at second multiply.
>      arr4 = scale * arr3
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jmiller at stsci.edu>




From nadavh at VisionSense.com  Sun Oct 19 08:13:21 2003
From: nadavh at VisionSense.com (Nadav Horesh)
Date: Sun Oct 19 08:13:21 2003
Subject: [Numpy-discussion] numarray.convolve bug and a fix
Message-ID: <1066566925.2830.29.camel@Nadav.Envision.co.il>

numarray.convolve.correlate2d (and probably some other functions in the
convolve module) doesn't work with the option fft=1.

Fix:
 in iraf_frame.py line 28 and Convolve.py line 136 replace
 "type=" by "typecode="

Nadav.




From Promoteing at 2911.net  Sun Oct 19 18:25:17 2003
From: Promoteing at 2911.net (Director)
Date: Sun Oct 19 18:25:17 2003
Subject: [Numpy-discussion] Marketing Support
Message-ID: <E1ABOXd-0001sn-Cz@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Karl Jackson
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From Promoteing at 2911.net  Mon Oct 20 04:01:40 2003
From: Promoteing at 2911.net (Director)
Date: Mon Oct 20 04:01:40 2003
Subject: [Numpy-discussion] Marketing
Message-ID: <E1ABXmR-0002Fp-QC@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Robert Jones
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From jmiller at stsci.edu  Mon Oct 20 12:41:14 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 20 12:41:14 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <3F91BC37.7060200@erols.com>
References: <3F91BC37.7060200@erols.com>
Message-ID: <1066678612.14017.197.camel@halloween.stsci.edu>

I tracked down the problem to some (relatively) new overflow checking
code which detects the overflow of the scalar -1 as it is assigned to an
array pseudo buffer of type UInt8.  This error was mishandled, and hence
was transformed into an invalid shape tuple (you gotta smile :-)).  The
*2nd* call is where the exception shows up because of caching logic.

I talked this over with Perry and we concluded that it's probably a good
thing to trap the out of range scalar values before using them.  Thus,
we're proposing to fix the error handling,  but to make the calls in
question raise an overflow exception on the first call.  We are
interested in hearing other opinions however.  Comments?

Regards,
Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Mon Oct 20 17:44:22 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 20 17:44:22 2003
Subject: [Numpy-discussion] numarray.convolve bug and a fix
In-Reply-To: <1066566925.2830.29.camel@Nadav.Envision.co.il>
References: <1066566925.2830.29.camel@Nadav.Envision.co.il>
Message-ID: <1066684186.14017.228.camel@halloween.stsci.edu>

Thanks Nadav,

I applied your suggestion to CVS and added a couple self-tests.

Regards,
Todd

On Sun, 2003-10-19 at 08:35, Nadav Horesh wrote:
> numarray.convolve.correlate2d (and probably some other functions in the
> convolve module) doesn't work with the option fft=1.
> 
> Fix:
>  in iraf_frame.py line 28 and Convolve.py line 136 replace
>  "type=" by "typecode="
> 
> Nadav.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From russ at coldstonelabs.org  Mon Oct 20 22:30:03 2003
From: russ at coldstonelabs.org (Russell Valentine)
Date: Mon Oct 20 22:30:03 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
Message-ID: <20031020232836.53359a6c.russ@coldstonelabs.org>

Hello,

   It may be my fault, but I think the following behaviour is odd. If I
try to change a array to a string it seems like it adds a lot of extra
zero characters. Take the following script attached as a example, it gives
me this output.

ta.tostring is not equal
Zero characters - 25
255 characters - 3
tast is equal
Zero characters - 4
255 characters - 3

tostring() is so much more faster than the second way, but it isn't giving
me the desired results. Have I done something wrong? I'm using Numeric
23.1

Thanks for your help.


Russell Valentine
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: NumericTest.py
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031020/7663b06f/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031020/7663b06f/attachment-0001.sig>

From falted at openlc.org  Tue Oct 21 02:02:29 2003
From: falted at openlc.org (Francesc Alted)
Date: Tue Oct 21 02:02:29 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <1066678612.14017.197.camel@halloween.stsci.edu>
References: <3F91BC37.7060200@erols.com> <1066678612.14017.197.camel@halloween.stsci.edu>
Message-ID: <200310210953.30323.falted@openlc.org>

A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?

You mean implementing range checking in numarray objects? In my opinion,
that would be a very nice feature, although I don't know how that would
affect the assignment performance.

-- 
Francesc Alted




From jmiller at stsci.edu  Tue Oct 21 07:34:02 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 07:34:02 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <200310210953.30323.falted@openlc.org>
References: <3F91BC37.7060200@erols.com>
	<1066678612.14017.197.camel@halloween.stsci.edu> 
	<200310210953.30323.falted@openlc.org>
Message-ID: <1066746638.1407.150.camel@halloween.stsci.edu>

On Tue, 2003-10-21 at 03:53, Francesc Alted wrote:
> A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> > I talked this over with Perry and we concluded that it's probably a good
> > thing to trap the out of range scalar values before using them.  Thus,
> > we're proposing to fix the error handling,  but to make the calls in
> > question raise an overflow exception on the first call.  We are
> > interested in hearing other opinions however.  Comments?
> 
> You mean implementing range checking in numarray objects? In my opinion,
> that would be a very nice feature, although I don't know how that would
> affect the assignment performance.

I don't anticipate any impact on performance for the limited scope we
were proposing:  overflow checking for the scalar parameters of binary
ufuncs.  There are other areas where overflow checking could be employed
but won't be.  So, trying to create a more coherent picture,

Here is where we will check for overflows:

1. fromlist(), if you specify check_overflow=1.  
2. scalar parameters of binary ufuncs.  So 1+a will make sure "1" fits
in the array implied by a.type().
3. non-array-sequence parameters of binary ufuncs.  So add(a,[1,2,3])
ensures that [1,2,3] can be stored in an array of the type implied by
array a. 
4. The multiply ufunc.
5. a[<single_element_index>] = x  whenever a._check_overflow is 1.

Here is where we won't check for overflows:

1. array(), or fromlist() by default.
2. most binary ufuncs.  So a+b won't check, assuming a and b are both
arrays.
3. a[<block_of_elements_index>] = b, regardless of a._check_overflow.

Comments?  Anything grossly inconsistent here?

> -- 
> Francesc Alted
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From nadavh at visionsense.com  Tue Oct 21 09:15:06 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 09:15:06 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E8066907@exchange2k.envision.co.il>

You have to convert ta to an (Unsigned)Int8 in order to make it work:

ta = N.array([0, 255, 255, 255,0,0,0], N.UnsignedInt8)
.......................................^^^^^^^^^^^^^^

The default integer type is 32 bits signed.

 Nadav.

-----Original Message-----
From:	Francesc Alted [mailto:falted at openlc.org]
Sent:	Tue 21-Oct-03 09:53
To:	numpy-discussion
Cc:	
Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
A Dilluns 20 Octubre 2003 21:36, Todd Miller va escriure:
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?

You mean implementing range checking in numarray objects? In my opinion,
that would be a very nice feature, although I don't know how that would
affect the assignment performance.

-- 
Francesc Alted



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion






From nadavh at visionsense.com  Tue Oct 21 09:16:09 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 09:16:09 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E8066906@exchange2k.envision.co.il>

As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
* State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
* State 2: Raise exception as suggested.
* State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:

>>> a = array((100,200,128), type=UInt8)
>>> a+a
array([200, 144,   0], type=UInt8)
>>> a*2
array([200, 255, 255], type=UInt8)

  Nadav

-----Original Message-----
From:	Todd Miller [mailto:jmiller at stsci.edu]
Sent:	Mon 20-Oct-03 21:36
To:	Edward C. Jones
Cc:	numpy-discussion
Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
I tracked down the problem to some (relatively) new overflow checking
code which detects the overflow of the scalar -1 as it is assigned to an
array pseudo buffer of type UInt8.  This error was mishandled, and hence
was transformed into an invalid shape tuple (you gotta smile :-)).  The
*2nd* call is where the exception shows up because of caching logic.

I talked this over with Perry and we concluded that it's probably a good
thing to trap the out of range scalar values before using them.  Thus,
we're proposing to fix the error handling,  but to make the calls in
question raise an overflow exception on the first call.  We are
interested in hearing other opinions however.  Comments?

Regards,
Todd

On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> # Python 2.3.2, numarray 0.7
> import numarray
> 
> def fun2(code, scale):
>      arr = numarray.ones((4,4), code)
>      arr2 = scale * arr
>      # Bug appears at second multiply.
>      arr3 = scale * arr
> 
> # These calls fail when "scale" is too big for "code":
> 
> #   File 
> "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> 653, in __rmul__
> #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> # ValueError: invalid shape tuple
> 
> #fun2('Int16', 100000)
> fun2('UInt8' , -1)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> Linux in the Boardroom; in the Front Office; & in the Server Room 
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion







From jmiller at stsci.edu  Tue Oct 21 09:59:28 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 09:59:28 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
In-Reply-To: <20031020232836.53359a6c.russ@coldstonelabs.org>
References: <20031020232836.53359a6c.russ@coldstonelabs.org>
Message-ID: <1066742169.955.51.camel@halloween.stsci.edu>

I think the problem is that the default integer precision is most likely
32-bits, and you appear to be assuming it will be 8-bits.  If you
declare your array using typecode=Numeric.UInt8 as an extra parameter,
you will force the type to match your assumption and things will work
out as you expect.

Regards,
Todd

On Tue, 2003-10-21 at 00:28, Russell Valentine wrote:
> Hello,
> 
>    It may be my fault, but I think the following behaviour is odd. If I
> try to change a array to a string it seems like it adds a lot of extra
> zero characters. Take the following script attached as a example, it gives
> me this output.
> 
> ta.tostring is not equal
> Zero characters - 25
> 255 characters - 3
> tast is equal
> Zero characters - 4
> 255 characters - 3
> 
> tostring() is so much more faster than the second way, but it isn't giving
> me the desired results. Have I done something wrong? I'm using Numeric
> 23.1
> 
> Thanks for your help.
> 
> 
> Russell Valentine
> ----
> 

> #!/bin/env python
> 
> import string
> import Numeric
> 
> 
> ta = Numeric.array([0, 255, 255, 255,0,0,0])
> compare_string = "\x00\xff\xff\xff\x00\x00\x00"
> if ta.tostring() == compare_string:
>     print "ta.tostring is equal"
> else:
>     print "ta.tostring is not equal"
> 
> print "Zero characters - "+str(ta.tostring().count("\x00"))
> print "255 characters - "+str(ta.tostring().count("\xff"))
> 
> tast = ""
> for value in ta:
>     tast += chr(value)
> 
> if tast == compare_string:
>     print "tast is equal"
> else:
>     print "tast is not equal"
> 
> print "Zero characters - "+str(tast.count("\x00"))
> print "255 characters - "+str(tast.count("\xff"))
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Tue Oct 21 10:33:11 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 10:33:11 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: 	<07C6A61102C94148B8104D42DE95F7E8066906@exchange2k.envision.co.il>
References: 	<07C6A61102C94148B8104D42DE95F7E8066906@exchange2k.envision.co.il>
Message-ID: <1066749150.955.167.camel@halloween.stsci.edu>

On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> * State 2: Raise exception as suggested.
> * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> 
> >>> a = array((100,200,128), type=UInt8)
> >>> a+a
> array([200, 144,   0], type=UInt8)
> >>> a*2
> array([200, 255, 255], type=UInt8)
> 
>   Nadav

This sounds like an attempt to turn a bug fix into a coherent plan. :)

We could implement what you're describing here a lot like we handle IEEE
floating point,  but I'm wondering if we should.  I think state 3 is
marginally portable, so I'm not sure we should support it,  but if we
did, what would we use it for? 

Similarly,  if we support both states 1 and 2,  is anyone going to be
sufficiently on the ball to know the difference and set their error
handling appropriately?  Or, are 99.9% of the people going to just use
whatever the default is?  If the latter is the case, we should just
implement "the default" and keep life simple.

I'm not opposed to this if there are valid uses for it,  but we should
know those reasons before implementing, and I don't.

Thanks for the ideas,
Todd

> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Mon 20-Oct-03 21:36
> To:	Edward C. Jones
> Cc:	numpy-discussion
> Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> I tracked down the problem to some (relatively) new overflow checking
> code which detects the overflow of the scalar -1 as it is assigned to an
> array pseudo buffer of type UInt8.  This error was mishandled, and hence
> was transformed into an invalid shape tuple (you gotta smile :-)).  The
> *2nd* call is where the exception shows up because of caching logic.
> 
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?
> 
> Regards,
> Todd
> 
> On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > #! /usr/bin/env python
> > 
> > # Python 2.3.2, numarray 0.7
> > import numarray
> > 
> > def fun2(code, scale):
> >      arr = numarray.ones((4,4), code)
> >      arr2 = scale * arr
> >      # Bug appears at second multiply.
> >      arr3 = scale * arr
> > 
> > # These calls fail when "scale" is too big for "code":
> > 
> > #   File 
> > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > 653, in __rmul__
> > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > # ValueError: invalid shape tuple
> > 
> > #fun2('Int16', 100000)
> > fun2('UInt8' , -1)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > http://www.enterpriselinuxforum.com
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From edcjones at erols.com  Tue Oct 21 12:11:15 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Tue Oct 21 12:11:15 2003
Subject: [Numpy-discussion] Doc bug for NA_New...
Message-ID: <3F956960.4050003@erols.com>

The source code for NA_vNewArray says "Call with buffer==NULL to 
allocate storage." This is handled in NA_NewAllFromBuffer and so applies 
to all the NA_New... functions. This needs to be mentioned in the 
documentation.

Ed Jones




From Chris.Barker at noaa.gov  Tue Oct 21 15:09:03 2003
From: Chris.Barker at noaa.gov (Chris Barker)
Date: Tue Oct 21 15:09:03 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
References: <20031020232836.53359a6c.russ@coldstonelabs.org>
Message-ID: <3F95447A.F779AC0F@noaa.gov>

Russell Valentine wrote:

>    It may be my fault, but I think the following behaviour is odd. If I
> try to change a array to a string it seems like it adds a lot of extra
> zero characters. Take the following script attached as a example, it gives
> me this output.

You've misunderstood what tostring() is supposed to do. It takes the
BINARY data representing the array, and dumps it into a Python string as
a string of bytes. It is NOT doing a chr() on each element. As an
example:

>>> a = array((1.0))
>>> # a is now a one element Python Float (C double, 8 bytes)
>>> s = a.tostring()
>>> len(s)
8
>>> print repr(s)
'\x00\x00\x00\x00\x00\x00\xf0?'
>>>

And there are your 8 bytes.

By the way, in your code:
tast = ""
for value in ta:
    tast += chr(value)

you could probably speed it up quite a bit by doing this instead:
tast = []
for value in ta:
    tast.append(value)
tast = "".join(tast)

Using += with a string creates a new string, one charactor longer, each
time. Appending to an a list is much faster, and the string join method
is pretty quick also.


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

Chris.Barker at noaa.gov



From jmiller at stsci.edu  Tue Oct 21 16:07:16 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 16:07:16 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: 	<07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
References: 	<07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
Message-ID: <1066769230.955.270.camel@halloween.stsci.edu>

On Tue, 2003-10-21 at 15:04, Nadav Horesh wrote:
> To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).

I see your point about the "singularity", but because of the new scalar
rules in numarray, checking for overflow seems necessary:  there is a
hidden downcast from the scalar to the array type for scalar_vector and
vector_scalar operations.  

> I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. 

My point was that without a reason to value consistency between the
overflow results of __add__ and __mul__, and with no guarantee that the
consistency is really obtainable anyway,  why worry about it?

> Why the __add__ operator should have the risk of being nonportable and __mul__ should not?

The reason __add__ and __mul__ are treated differently is that there is
a different "probability" of overflow for each.  With __mul__, overflow
is much more likely, so we deal with it and try to flag the elements
where it occurred.  With __add__, we don't want to pay the significant
performance penalty of checking for overflow.

> Which state should be the default?
> There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).

Your arguments all make sense to me Nadav, but it ultimately boils down
to what level of overflow checking we have the will to implement.  Right
now, we have the will to fix the bug in the vector scalar error handling
and a simple choice of what to do with one particular new error we've
uncovered: ignore it or trap it.

Regards,
Todd

> 
>   Nadav.
> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Tue 21-Oct-03 17:12
> To:	Nadav Horesh
> Cc:	Edward C. Jones; numpy-discussion
> Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
> On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> > As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> > * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> > * State 2: Raise exception as suggested.
> > * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> > 
> > >>> a = array((100,200,128), type=UInt8)
> > >>> a+a
> > array([200, 144,   0], type=UInt8)
> > >>> a*2
> > array([200, 255, 255], type=UInt8)
> > 
> >   Nadav
> 
> This sounds like an attempt to turn a bug fix into a coherent plan. :)
> 
> We could implement what you're describing here a lot like we handle IEEE
> floating point,  but I'm wondering if we should.  I think state 3 is
> marginally portable, so I'm not sure we should support it,  but if we
> did, what would we use it for? 
> 
> Similarly,  if we support both states 1 and 2,  is anyone going to be
> sufficiently on the ball to know the difference and set their error
> handling appropriately?  Or, are 99.9% of the people going to just use
> whatever the default is?  If the latter is the case, we should just
> implement "the default" and keep life simple.
> 
> I'm not opposed to this if there are valid uses for it,  but we should
> know those reasons before implementing, and I don't.
> 
> Thanks for the ideas,
> Todd
> 
> > 
> > -----Original Message-----
> > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > Sent:	Mon 20-Oct-03 21:36
> > To:	Edward C. Jones
> > Cc:	numpy-discussion
> > Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> > I tracked down the problem to some (relatively) new overflow checking
> > code which detects the overflow of the scalar -1 as it is assigned to an
> > array pseudo buffer of type UInt8.  This error was mishandled, and hence
> > was transformed into an invalid shape tuple (you gotta smile :-)).  The
> > *2nd* call is where the exception shows up because of caching logic.
> > 
> > I talked this over with Perry and we concluded that it's probably a good
> > thing to trap the out of range scalar values before using them.  Thus,
> > we're proposing to fix the error handling,  but to make the calls in
> > question raise an overflow exception on the first call.  We are
> > interested in hearing other opinions however.  Comments?
> > 
> > Regards,
> > Todd
> > 
> > On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > > #! /usr/bin/env python
> > > 
> > > # Python 2.3.2, numarray 0.7
> > > import numarray
> > > 
> > > def fun2(code, scale):
> > >      arr = numarray.ones((4,4), code)
> > >      arr2 = scale * arr
> > >      # Bug appears at second multiply.
> > >      arr3 = scale * arr
> > > 
> > > # These calls fail when "scale" is too big for "code":
> > > 
> > > #   File 
> > > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > > 653, in __rmul__
> > > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > > # ValueError: invalid shape tuple
> > > 
> > > #fun2('Int16', 100000)
> > > fun2('UInt8' , -1)
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > > http://www.enterpriselinuxforum.com
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Numpy-discussion at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > -- 
> > Todd Miller 			
> > Space Telescope Science Institute
> > 3700 San Martin Drive
> > Baltimore MD, 21030
> > (410) 338 - 4576
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by OSDN developer relations
> > Here's your chance to show off your extensive product knowledge
> > We want to know what you know. Tell us and you have a chance to win $100
> > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > 
> > 
> > 
> > 
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From russ at coldstonelabs.org  Tue Oct 21 17:00:10 2003
From: russ at coldstonelabs.org (Russell Valentine)
Date: Tue Oct 21 17:00:10 2003
Subject: [Numpy-discussion] Numeric odd tostring() behaviour
In-Reply-To: <1066742169.955.51.camel@halloween.stsci.edu>
References: <20031020232836.53359a6c.russ@coldstonelabs.org>
	<1066742169.955.51.camel@halloween.stsci.edu>
Message-ID: <20031021164435.36801a7f.russ@coldstonelabs.org>



I understand my error. Everyone who responded, you have my thanks.


Russell Valentine


On 21 Oct 2003 09:16:08 -0400
Todd Miller <jmiller at stsci.edu> wrote:

> I think the problem is that the default integer precision is most likely
> 32-bits, and you appear to be assuming it will be 8-bits.  If you
> declare your array using typecode=Numeric.UInt8 as an extra parameter,
> you will force the type to match your assumption and things will work
> out as you expect.
> 
> Regards,
> Todd
> 
> On Tue, 2003-10-21 at 00:28, Russell Valentine wrote:
> > Hello,
> > 
> >    It may be my fault, but I think the following behaviour is odd. If
> >    I
> > try to change a array to a string it seems like it adds a lot of extra
> > zero characters. Take the following script attached as a example, it
> > gives me this output.
> > 
> > ta.tostring is not equal
> > Zero characters - 25
> > 255 characters - 3
> > tast is equal
> > Zero characters - 4
> > 255 characters - 3
> > 
> > tostring() is so much more faster than the second way, but it isn't
> > giving me the desired results. Have I done something wrong? I'm using
> > Numeric 23.1
> > 
> > Thanks for your help.
> > 
> > 
> > Russell Valentine
> > ----
> > 
> 
> > #!/bin/env python
> > 
> > import string
> > import Numeric
> > 
> > 
> > ta = Numeric.array([0, 255, 255, 255,0,0,0])
> > compare_string = "\x00\xff\xff\xff\x00\x00\x00"
> > if ta.tostring() == compare_string:
> >     print "ta.tostring is equal"
> > else:
> >     print "ta.tostring is not equal"
> > 
> > print "Zero characters - "+str(ta.tostring().count("\x00"))
> > print "255 characters - "+str(ta.tostring().count("\xff"))
> > 
> > tast = ""
> > for value in ta:
> >     tast += chr(value)
> > 
> > if tast == compare_string:
> >     print "tast is equal"
> > else:
> >     print "tast is not equal"
> > 
> > print "Zero characters - "+str(tast.count("\x00"))
> > print "255 characters - "+str(tast.count("\xff"))
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20031021/7c43a546/attachment-0001.sig>

From jmiller at stsci.edu  Tue Oct 21 18:13:12 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Tue Oct 21 18:13:12 2003
Subject: [Numpy-discussion] Doc bug for NA_New...
In-Reply-To: <3F956960.4050003@erols.com>
References: <3F956960.4050003@erols.com>
Message-ID: <1066774740.955.274.camel@halloween.stsci.edu>

I added a comment to each of the function definitions.

Thanks,
Todd

On Tue, 2003-10-21 at 13:14, Edward C. Jones wrote:
> The source code for NA_vNewArray says "Call with buffer==NULL to 
> allocate storage." This is handled in NA_NewAllFromBuffer and so applies 
> to all the NA_New... functions. This needs to be mentioned in the 
> documentation.
> 
> Ed Jones
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From nadavh at visionsense.com  Tue Oct 21 20:05:10 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 20:05:10 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>

To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).

I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. Why the __add__ operator should have the risk of being nonportable and __mul__ should not?

Which state should be the default?
There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).

  Nadav.

-----Original Message-----
From:	Todd Miller [mailto:jmiller at stsci.edu]
Sent:	Tue 21-Oct-03 17:12
To:	Nadav Horesh
Cc:	Edward C. Jones; numpy-discussion
Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> * State 2: Raise exception as suggested.
> * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> 
> >>> a = array((100,200,128), type=UInt8)
> >>> a+a
> array([200, 144,   0], type=UInt8)
> >>> a*2
> array([200, 255, 255], type=UInt8)
> 
>   Nadav

This sounds like an attempt to turn a bug fix into a coherent plan. :)

We could implement what you're describing here a lot like we handle IEEE
floating point,  but I'm wondering if we should.  I think state 3 is
marginally portable, so I'm not sure we should support it,  but if we
did, what would we use it for? 

Similarly,  if we support both states 1 and 2,  is anyone going to be
sufficiently on the ball to know the difference and set their error
handling appropriately?  Or, are 99.9% of the people going to just use
whatever the default is?  If the latter is the case, we should just
implement "the default" and keep life simple.

I'm not opposed to this if there are valid uses for it,  but we should
know those reasons before implementing, and I don't.

Thanks for the ideas,
Todd

> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Mon 20-Oct-03 21:36
> To:	Edward C. Jones
> Cc:	numpy-discussion
> Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> I tracked down the problem to some (relatively) new overflow checking
> code which detects the overflow of the scalar -1 as it is assigned to an
> array pseudo buffer of type UInt8.  This error was mishandled, and hence
> was transformed into an invalid shape tuple (you gotta smile :-)).  The
> *2nd* call is where the exception shows up because of caching logic.
> 
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?
> 
> Regards,
> Todd
> 
> On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > #! /usr/bin/env python
> > 
> > # Python 2.3.2, numarray 0.7
> > import numarray
> > 
> > def fun2(code, scale):
> >      arr = numarray.ones((4,4), code)
> >      arr2 = scale * arr
> >      # Bug appears at second multiply.
> >      arr3 = scale * arr
> > 
> > # These calls fail when "scale" is too big for "code":
> > 
> > #   File 
> > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > 653, in __rmul__
> > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > # ValueError: invalid shape tuple
> > 
> > #fun2('Int16', 100000)
> > fun2('UInt8' , -1)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > http://www.enterpriselinuxforum.com
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion






From nadavh at visionsense.com  Tue Oct 21 20:26:25 2003
From: nadavh at visionsense.com (Nadav Horesh)
Date: Tue Oct 21 20:26:25 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
Message-ID: <07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>

To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).

I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. Why the __add__ operator should have the risk of being nonportable and __mul__ should not?

Which state should be the default?
There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).

  Nadav.

-----Original Message-----
From:	Todd Miller [mailto:jmiller at stsci.edu]
Sent:	Tue 21-Oct-03 17:12
To:	Nadav Horesh
Cc:	Edward C. Jones; numpy-discussion
Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> * State 2: Raise exception as suggested.
> * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> 
> >>> a = array((100,200,128), type=UInt8)
> >>> a+a
> array([200, 144,   0], type=UInt8)
> >>> a*2
> array([200, 255, 255], type=UInt8)
> 
>   Nadav

This sounds like an attempt to turn a bug fix into a coherent plan. :)

We could implement what you're describing here a lot like we handle IEEE
floating point,  but I'm wondering if we should.  I think state 3 is
marginally portable, so I'm not sure we should support it,  but if we
did, what would we use it for? 

Similarly,  if we support both states 1 and 2,  is anyone going to be
sufficiently on the ball to know the difference and set their error
handling appropriately?  Or, are 99.9% of the people going to just use
whatever the default is?  If the latter is the case, we should just
implement "the default" and keep life simple.

I'm not opposed to this if there are valid uses for it,  but we should
know those reasons before implementing, and I don't.

Thanks for the ideas,
Todd

> 
> -----Original Message-----
> From:	Todd Miller [mailto:jmiller at stsci.edu]
> Sent:	Mon 20-Oct-03 21:36
> To:	Edward C. Jones
> Cc:	numpy-discussion
> Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> I tracked down the problem to some (relatively) new overflow checking
> code which detects the overflow of the scalar -1 as it is assigned to an
> array pseudo buffer of type UInt8.  This error was mishandled, and hence
> was transformed into an invalid shape tuple (you gotta smile :-)).  The
> *2nd* call is where the exception shows up because of caching logic.
> 
> I talked this over with Perry and we concluded that it's probably a good
> thing to trap the out of range scalar values before using them.  Thus,
> we're proposing to fix the error handling,  but to make the calls in
> question raise an overflow exception on the first call.  We are
> interested in hearing other opinions however.  Comments?
> 
> Regards,
> Todd
> 
> On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > #! /usr/bin/env python
> > 
> > # Python 2.3.2, numarray 0.7
> > import numarray
> > 
> > def fun2(code, scale):
> >      arr = numarray.ones((4,4), code)
> >      arr2 = scale * arr
> >      # Bug appears at second multiply.
> >      arr3 = scale * arr
> > 
> > # These calls fail when "scale" is too big for "code":
> > 
> > #   File 
> > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > 653, in __rmul__
> > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > # ValueError: invalid shape tuple
> > 
> > #fun2('Int16', 100000)
> > fun2('UInt8' , -1)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > http://www.enterpriselinuxforum.com
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> -- 
> Todd Miller 			
> Space Telescope Science Institute
> 3700 San Martin Drive
> Baltimore MD, 21030
> (410) 338 - 4576
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 
> 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion






From nadavh at VisionSense.com  Wed Oct 22 06:59:08 2003
From: nadavh at VisionSense.com (Nadav Horesh)
Date: Wed Oct 22 06:59:08 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <1066769230.955.270.camel@halloween.stsci.edu>
References: 	 <07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
	 <1066769230.955.270.camel@halloween.stsci.edu>
Message-ID: <1066831865.9252.42.camel@Nadav.Envision.co.il>

O.K. got your case (and you certainly have one).

But ...
  in the long run, wouldn't it be nice to give an option to remove all
checking (and thus produce a machine dependent under/overflow treatment)
for those who opt for speed?

 Really enjoyed this discussion,

    Nadav.

On Tue, 2003-10-21 at 22:47, Todd Miller wrote:
> On Tue, 2003-10-21 at 15:04, Nadav Horesh wrote:
> > To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).
> 
> I see your point about the "singularity", but because of the new scalar
> rules in numarray, checking for overflow seems necessary:  there is a
> hidden downcast from the scalar to the array type for scalar_vector and
> vector_scalar operations.  
> 
> > I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. 
> 
> My point was that without a reason to value consistency between the
> overflow results of __add__ and __mul__, and with no guarantee that the
> consistency is really obtainable anyway,  why worry about it?
> 
> > Why the __add__ operator should have the risk of being nonportable and __mul__ should not?
> 
> The reason __add__ and __mul__ are treated differently is that there is
> a different "probability" of overflow for each.  With __mul__, overflow
> is much more likely, so we deal with it and try to flag the elements
> where it occurred.  With __add__, we don't want to pay the significant
> performance penalty of checking for overflow.
> 
> > Which state should be the default?
> > There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).
> 
> Your arguments all make sense to me Nadav, but it ultimately boils down
> to what level of overflow checking we have the will to implement.  Right
> now, we have the will to fix the bug in the vector scalar error handling
> and a simple choice of what to do with one particular new error we've
> uncovered: ignore it or trap it.
> 
> Regards,
> Todd
> 
> > 
> >   Nadav.
> > 
> > -----Original Message-----
> > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > Sent:	Tue 21-Oct-03 17:12
> > To:	Nadav Horesh
> > Cc:	Edward C. Jones; numpy-discussion
> > Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
> > On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> > > As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> > > * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> > > * State 2: Raise exception as suggested.
> > > * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> > > 
> > > >>> a = array((100,200,128), type=UInt8)
> > > >>> a+a
> > > array([200, 144,   0], type=UInt8)
> > > >>> a*2
> > > array([200, 255, 255], type=UInt8)
> > > 
> > >   Nadav
> > 
> > This sounds like an attempt to turn a bug fix into a coherent plan. :)
> > 
> > We could implement what you're describing here a lot like we handle IEEE
> > floating point,  but I'm wondering if we should.  I think state 3 is
> > marginally portable, so I'm not sure we should support it,  but if we
> > did, what would we use it for? 
> > 
> > Similarly,  if we support both states 1 and 2,  is anyone going to be
> > sufficiently on the ball to know the difference and set their error
> > handling appropriately?  Or, are 99.9% of the people going to just use
> > whatever the default is?  If the latter is the case, we should just
> > implement "the default" and keep life simple.
> > 
> > I'm not opposed to this if there are valid uses for it,  but we should
> > know those reasons before implementing, and I don't.
> > 
> > Thanks for the ideas,
> > Todd
> > 
> > > 
> > > -----Original Message-----
> > > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > > Sent:	Mon 20-Oct-03 21:36
> > > To:	Edward C. Jones
> > > Cc:	numpy-discussion
> > > Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> > > I tracked down the problem to some (relatively) new overflow checking
> > > code which detects the overflow of the scalar -1 as it is assigned to an
> > > array pseudo buffer of type UInt8.  This error was mishandled, and hence
> > > was transformed into an invalid shape tuple (you gotta smile :-)).  The
> > > *2nd* call is where the exception shows up because of caching logic.
> > > 
> > > I talked this over with Perry and we concluded that it's probably a good
> > > thing to trap the out of range scalar values before using them.  Thus,
> > > we're proposing to fix the error handling,  but to make the calls in
> > > question raise an overflow exception on the first call.  We are
> > > interested in hearing other opinions however.  Comments?
> > > 
> > > Regards,
> > > Todd
> > > 
> > > On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > > > #! /usr/bin/env python
> > > > 
> > > > # Python 2.3.2, numarray 0.7
> > > > import numarray
> > > > 
> > > > def fun2(code, scale):
> > > >      arr = numarray.ones((4,4), code)
> > > >      arr2 = scale * arr
> > > >      # Bug appears at second multiply.
> > > >      arr3 = scale * arr
> > > > 
> > > > # These calls fail when "scale" is too big for "code":
> > > > 
> > > > #   File 
> > > > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > > > 653, in __rmul__
> > > > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > > > # ValueError: invalid shape tuple
> > > > 
> > > > #fun2('Int16', 100000)
> > > > fun2('UInt8' , -1)
> > > > 
> > > > 
> > > > 
> > > > -------------------------------------------------------
> > > > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > > > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > > > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > > > http://www.enterpriselinuxforum.com
> > > > _______________________________________________
> > > > Numpy-discussion mailing list
> > > > Numpy-discussion at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > -- 
> > > Todd Miller 			
> > > Space Telescope Science Institute
> > > 3700 San Martin Drive
> > > Baltimore MD, 21030
> > > (410) 338 - 4576
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by OSDN developer relations
> > > Here's your chance to show off your extensive product knowledge
> > > We want to know what you know. Tell us and you have a chance to win $100
> > > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Numpy-discussion at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > 
> > > 
> > > 
> > > 
> > -- 
> > Todd Miller 			
> > Space Telescope Science Institute
> > 3700 San Martin Drive
> > Baltimore MD, 21030
> > (410) 338 - 4576
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by OSDN developer relations
> > Here's your chance to show off your extensive product knowledge
> > We want to know what you know. Tell us and you have a chance to win $100
> > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > _______________________________________________
> > Numpy-discussion mailing list
> > Numpy-discussion at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > 
> > 
> > 




From jmiller at stsci.edu  Wed Oct 22 08:27:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Wed Oct 22 08:27:04 2003
Subject: [Numpy-discussion] Possible bug in scalar * array
In-Reply-To: <1066831865.9252.42.camel@Nadav.Envision.co.il>
References: 	<07C6A61102C94148B8104D42DE95F7E806690A@exchange2k.envision.co.il>
	<1066769230.955.270.camel@halloween.stsci.edu> 
	<1066831865.9252.42.camel@Nadav.Envision.co.il>
Message-ID: <1066831245.1575.5.camel@halloween.stsci.edu>

On Wed, 2003-10-22 at 10:11, Nadav Horesh wrote:
> O.K. got your case (and you certainly have one).
> 
> But ...
>   in the long run, wouldn't it be nice to give an option to remove all
> checking (and thus produce a machine dependent under/overflow treatment)
> for those who opt for speed?

Yes,  it would be nice,  but... not nice enough to "actually do it."  
If it is important enough,  eventually there will be a clamor for action
which I don't see right now.

> 
>  Really enjoyed this discussion,
> 
>     Nadav.

Me too.  Thanks for the input,

Todd

> 
> On Tue, 2003-10-21 at 22:47, Todd Miller wrote:
> > On Tue, 2003-10-21 at 15:04, Nadav Horesh wrote:
> > > To my opinion state 2 is surplus: Consider a large loop where an integer array s are multiplied by a wide range of scalars, and, at some point an exception is raised; It is not easy to track down what happened, especially when the scalars are not ordered (say, read from a data file). I can not find any justification for state 2 singularity (A*n is ok, A*(n+1) is not).
> > 
> > I see your point about the "singularity", but because of the new scalar
> > rules in numarray, checking for overflow seems necessary:  there is a
> > hidden downcast from the scalar to the array type for scalar_vector and
> > vector_scalar operations.  
> > 
> > > I suspect that state 3 is the fastest (it is up to you to judge), it is also consistent with the behavior of the __add__ operator. 
> > 
> > My point was that without a reason to value consistency between the
> > overflow results of __add__ and __mul__, and with no guarantee that the
> > consistency is really obtainable anyway,  why worry about it?
> > 
> > > Why the __add__ operator should have the risk of being nonportable and __mul__ should not?
> > 
> > The reason __add__ and __mul__ are treated differently is that there is
> > a different "probability" of overflow for each.  With __mul__, overflow
> > is much more likely, so we deal with it and try to flag the elements
> > where it occurred.  With __add__, we don't want to pay the significant
> > performance penalty of checking for overflow.
> > 
> > > Which state should be the default?
> > > There are two way to use the system: interactive and in a script. To my opinion the default should be the state that fits more the interactive mode --- slower and with a lot of checking. Maybe it is better to add a section to the documentation, how to tune the package for maximum performance: those who are interested in a high performance computing should be ready to do some extra work (read the manual, at least).
> > 
> > Your arguments all make sense to me Nadav, but it ultimately boils down
> > to what level of overflow checking we have the will to implement.  Right
> > now, we have the will to fix the bug in the vector scalar error handling
> > and a simple choice of what to do with one particular new error we've
> > uncovered: ignore it or trap it.
> > 
> > Regards,
> > Todd
> > 
> > > 
> > >   Nadav.
> > > 
> > > -----Original Message-----
> > > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > > Sent:	Tue 21-Oct-03 17:12
> > > To:	Nadav Horesh
> > > Cc:	Edward C. Jones; numpy-discussion
> > > Subject:	RE: [Numpy-discussion] Possible bug in scalar * array
> > > On Tue, 2003-10-21 at 10:07, Nadav Horesh wrote:
> > > > As I underoustand the range checking (from the results --- not from the source code), it checks if the range of the scalar exceeds the range of the array elements type. Don't see any significant execution time penalty with that. However there might be a place for a flag-controlled behavior:
> > > > * State 1: stay with the current "saturated" over/underflow whatever the scalar is. This is consistent with what numarray does now with scalars in range.
> > > > * State 2: Raise exception as suggested.
> > > > * State 3: Use the normal wrap-around on integer overflow, thus make a*2 give the same results as a+a in the following example:
> > > > 
> > > > >>> a = array((100,200,128), type=UInt8)
> > > > >>> a+a
> > > > array([200, 144,   0], type=UInt8)
> > > > >>> a*2
> > > > array([200, 255, 255], type=UInt8)
> > > > 
> > > >   Nadav
> > > 
> > > This sounds like an attempt to turn a bug fix into a coherent plan. :)
> > > 
> > > We could implement what you're describing here a lot like we handle IEEE
> > > floating point,  but I'm wondering if we should.  I think state 3 is
> > > marginally portable, so I'm not sure we should support it,  but if we
> > > did, what would we use it for? 
> > > 
> > > Similarly,  if we support both states 1 and 2,  is anyone going to be
> > > sufficiently on the ball to know the difference and set their error
> > > handling appropriately?  Or, are 99.9% of the people going to just use
> > > whatever the default is?  If the latter is the case, we should just
> > > implement "the default" and keep life simple.
> > > 
> > > I'm not opposed to this if there are valid uses for it,  but we should
> > > know those reasons before implementing, and I don't.
> > > 
> > > Thanks for the ideas,
> > > Todd
> > > 
> > > > 
> > > > -----Original Message-----
> > > > From:	Todd Miller [mailto:jmiller at stsci.edu]
> > > > Sent:	Mon 20-Oct-03 21:36
> > > > To:	Edward C. Jones
> > > > Cc:	numpy-discussion
> > > > Subject:	Re: [Numpy-discussion] Possible bug in scalar * array
> > > > I tracked down the problem to some (relatively) new overflow checking
> > > > code which detects the overflow of the scalar -1 as it is assigned to an
> > > > array pseudo buffer of type UInt8.  This error was mishandled, and hence
> > > > was transformed into an invalid shape tuple (you gotta smile :-)).  The
> > > > *2nd* call is where the exception shows up because of caching logic.
> > > > 
> > > > I talked this over with Perry and we concluded that it's probably a good
> > > > thing to trap the out of range scalar values before using them.  Thus,
> > > > we're proposing to fix the error handling,  but to make the calls in
> > > > question raise an overflow exception on the first call.  We are
> > > > interested in hearing other opinions however.  Comments?
> > > > 
> > > > Regards,
> > > > Todd
> > > > 
> > > > On Sat, 2003-10-18 at 18:18, Edward C. Jones wrote:
> > > > > #! /usr/bin/env python
> > > > > 
> > > > > # Python 2.3.2, numarray 0.7
> > > > > import numarray
> > > > > 
> > > > > def fun2(code, scale):
> > > > >      arr = numarray.ones((4,4), code)
> > > > >      arr2 = scale * arr
> > > > >      # Bug appears at second multiply.
> > > > >      arr3 = scale * arr
> > > > > 
> > > > > # These calls fail when "scale" is too big for "code":
> > > > > 
> > > > > #   File 
> > > > > "/usr/local/lib/python2.3/site-packages/numarray/numarraycore.py", line 
> > > > > 653, in __rmul__
> > > > > #    def __rmul__(self, operand): return ufunc.multiply(operand, self)
> > > > > # ValueError: invalid shape tuple
> > > > > 
> > > > > #fun2('Int16', 100000)
> > > > > fun2('UInt8' , -1)
> > > > > 
> > > > > 
> > > > > 
> > > > > -------------------------------------------------------
> > > > > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> > > > > The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
> > > > > Linux in the Boardroom; in the Front Office; & in the Server Room 
> > > > > http://www.enterpriselinuxforum.com
> > > > > _______________________________________________
> > > > > Numpy-discussion mailing list
> > > > > Numpy-discussion at lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > > -- 
> > > > Todd Miller 			
> > > > Space Telescope Science Institute
> > > > 3700 San Martin Drive
> > > > Baltimore MD, 21030
> > > > (410) 338 - 4576
> > > > 
> > > > 
> > > > 
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by OSDN developer relations
> > > > Here's your chance to show off your extensive product knowledge
> > > > We want to know what you know. Tell us and you have a chance to win $100
> > > > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > > > _______________________________________________
> > > > Numpy-discussion mailing list
> > > > Numpy-discussion at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > > 
> > > > 
> > > > 
> > > > 
> > > -- 
> > > Todd Miller 			
> > > Space Telescope Science Institute
> > > 3700 San Martin Drive
> > > Baltimore MD, 21030
> > > (410) 338 - 4576
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by OSDN developer relations
> > > Here's your chance to show off your extensive product knowledge
> > > We want to know what you know. Tell us and you have a chance to win $100
> > > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > > _______________________________________________
> > > Numpy-discussion mailing list
> > > Numpy-discussion at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> > > 
> > > 
> > > 
> 
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From Promoteing at 2911.net  Wed Oct 22 13:46:17 2003
From: Promoteing at 2911.net (Marketing)
Date: Wed Oct 22 13:46:17 2003
Subject: [Numpy-discussion] Marketing Details
Message-ID: <E1ACPTC-0003bL-9m@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Robert Jones
Sales & Marketing
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From cjw at sympatico.ca  Wed Oct 22 18:29:12 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Wed Oct 22 18:29:12 2003
Subject: [Numpy-discussion] Documentation using PyDoc
Message-ID: <3F971078.3030309@sympatico.ca>

[Message copied to comp.lang.python]

I am building a module which is based on the numarray package and its 
sub-packages.

I am proposing to use PyDoc to document this module.  The problem is 
that PyDoc generates links to documentation on the imported modules and 
expects to find HTML files in the style: nameOfImportedModule.html.

The numarray documentation is not in this style.

Is there some way that I can guide PyDoc in the generation of names to 
the imported links?

Supposing I create my own links, how can I ensure that these 
automatically call the appropriate node in the numarray tree?

Is there any possibility that the numarray documentation could be 
generated by PyDoc?

I would appreciate any advice.

Colin W.

PS I don't see any documentation on the generic module.







From edcjones at erols.com  Thu Oct 23 10:47:31 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Thu Oct 23 10:47:31 2003
Subject: [Numpy-discussion] Incorrect OverflowError?
Message-ID: <3F97F56E.5000700@erols.com>

#! /usr/bin/env python

import numarray
from numarray.numerictypes import *

# I run Gentoo 1.4 Linux with gcc 3.2.2.

numarray.Error.setMode(all='ignore')

arr = numarray.zeros((1,), Float64)
arr[0] = 4000000000.0
print '%f' % arr[0]
try:
     arr[0] = 4000000000
     print "Doesn't get here."
except OverflowError, s:
     print 'Python OverflowError raised'
     print s
# OverflowError: long int too large to convert to int

# The Python long "4000000000" can be represented as a C double.
# If the OverflowError came from numarray, why was an exception raised?
# Are these problems bugs?




From cjw at sympatico.ca  Thu Oct 23 12:27:11 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Thu Oct 23 12:27:11 2003
Subject: [Numpy-discussion] Symmetry of functions
Message-ID: <3F982AC5.8000806@sympatico.ca>

A suggestion:

fromstring accepts a string - tostring returns a string
fromfile accepts a file        -  tofile returns None

This is to suggest that generic.tofile be modified
to return the file object, which may be open or
closed.

Colin W.





From cjw at sympatico.ca  Thu Oct 23 13:31:11 2003
From: cjw at sympatico.ca (Colin J. Williams)
Date: Thu Oct 23 13:31:11 2003
Subject: [Numpy-discussion] Documentation using PyDoc
In-Reply-To: <1066916588.19211.62.camel@halloween.stsci.edu>
References: <3F971078.3030309@sympatico.ca> <1066916588.19211.62.camel@halloween.stsci.edu>
Message-ID: <3F97EA03.10101@sympatico.ca>

Todd,

Many thanks, you've suggested the obvious (now) - generate my own.

Thanks, I should have thought of this.

The only relatively minor problem is that my package will need to update 
thes generated files as numarray progresses.

Colin W.

PS Richard Jones has suggested ePyDoc as an enhanced PyDoc.  I'll look 
at that.

Todd Miller wrote:

>On Wed, 2003-10-22 at 19:19, Colin J. Williams wrote:
>  
>
>>[Message copied to comp.lang.python]
>>
>>I am building a module which is based on the numarray package and its 
>>sub-packages.
>>
>>I am proposing to use PyDoc to document this module.  The problem is 
>>that PyDoc generates links to documentation on the imported modules and 
>>expects to find HTML files in the style: nameOfImportedModule.html.
>>
>>    
>>
>I'm not sure I fully understand the problem,  but I just tried:
>
>  
>
>>>>import pydoc
>>>>pydoc.writedoc("numarray.generic")
>>>>        
>>>>
>
>This produced numarray.generic.html.
>
>  
>
>>The numarray documentation is not in this style.
>>    
>>
>
>The manual certainly isn't,  but is Python's own manual in this style?
> 
>  
>
>>Is there some way that I can guide PyDoc in the generation of names to 
>>the imported links?
>>    
>>
>
>See above.
>
>  
>
>>Supposing I create my own links, how can I ensure that these 
>>automatically call the appropriate node in the numarray tree?
>>
>>Is there any possibility that the numarray documentation could be 
>>generated by PyDoc?
>>    
>>
>
>Yes and no.  Numarray already has doc-strings which probably need more
>work. The numarray manual is not going to suddenly transform into pydoc
>format.
> 
>  
>
>>I would appreciate any advice.
>>    
>>
>
>That's my $.02
>
>  
>
>>Colin W.
>>
>>PS I don't see any documentation on the generic module.
>>
>>    
>>
>What information exists is recorded in a combination of the manual, the
>generic.py doc-strings, and Doc/design.txt.  design.txt looks like it
>has some bit-rot (especially the C-API).
>
>There's probably not as much info as you want,  but I think what you're
>trying to do (create an NDArray or NumArray subclass) is at the
>forefront of numarray development so you may to have to read code or ask
>specific questions to find out what you want to know.
>
>Regards, 
>Todd
>  
>




From jmiller at stsci.edu  Thu Oct 23 13:31:25 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Thu Oct 23 13:31:25 2003
Subject: [Numpy-discussion] Incorrect OverflowError?
In-Reply-To: <3F97F56E.5000700@erols.com>
References: <3F97F56E.5000700@erols.com>
Message-ID: <1066940559.19432.118.camel@halloween.stsci.edu>

On Thu, 2003-10-23 at 11:36, Edward C. Jones wrote:
> #! /usr/bin/env python
> 
> import numarray
> from numarray.numerictypes import *
> 
> # I run Gentoo 1.4 Linux with gcc 3.2.2.
> 
> numarray.Error.setMode(all='ignore')
> 
> arr = numarray.zeros((1,), Float64)
> arr[0] = 4000000000.0
> print '%f' % arr[0]
> try:
>      arr[0] = 4000000000
>      print "Doesn't get here."
> except OverflowError, s:
>      print 'Python OverflowError raised'
>      print s
> # OverflowError: long int too large to convert to int
> 
> # The Python long "4000000000" can be represented as a C double.
> # If the OverflowError came from numarray, why was an exception raised?
> # Are these problems bugs?
> 
Yes.  The bug was a use of PyLong_AsLong instead of PyLong_AsLongLong. 
Keep looking!  :-)

Thanks,
Todd
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Thu Oct 23 16:04:04 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Thu Oct 23 16:04:04 2003
Subject: [Numpy-discussion] Documentation using PyDoc
In-Reply-To: <3F971078.3030309@sympatico.ca>
References: <3F971078.3030309@sympatico.ca>
Message-ID: <1066916588.19211.62.camel@halloween.stsci.edu>

On Wed, 2003-10-22 at 19:19, Colin J. Williams wrote:
> [Message copied to comp.lang.python]
> 
> I am building a module which is based on the numarray package and its 
> sub-packages.
> 
> I am proposing to use PyDoc to document this module.  The problem is 
> that PyDoc generates links to documentation on the imported modules and 
> expects to find HTML files in the style: nameOfImportedModule.html.
> 
I'm not sure I fully understand the problem,  but I just tried:

>>> import pydoc
>>> pydoc.writedoc("numarray.generic")

This produced numarray.generic.html.

> The numarray documentation is not in this style.

The manual certainly isn't,  but is Python's own manual in this style?
 
> Is there some way that I can guide PyDoc in the generation of names to 
> the imported links?

See above.

> Supposing I create my own links, how can I ensure that these 
> automatically call the appropriate node in the numarray tree?
> 
> Is there any possibility that the numarray documentation could be 
> generated by PyDoc?

Yes and no.  Numarray already has doc-strings which probably need more
work. The numarray manual is not going to suddenly transform into pydoc
format.
 
> I would appreciate any advice.

That's my $.02

> Colin W.
> 
> PS I don't see any documentation on the generic module.
> 
What information exists is recorded in a combination of the manual, the
generic.py doc-strings, and Doc/design.txt.  design.txt looks like it
has some bit-rot (especially the C-API).

There's probably not as much info as you want,  but I think what you're
trying to do (create an NDArray or NumArray subclass) is at the
forefront of numarray development so you may to have to read code or ask
specific questions to find out what you want to know.

Regards, 
Todd
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From edcjones at erols.com  Thu Oct 23 18:26:13 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Thu Oct 23 18:26:13 2003
Subject: [Numpy-discussion] NA_getType needs to be documented
Message-ID: <3F9876D9.8040905@erols.com>

"NA_getType" needs to be documented. The following is useful:

     if (!PyArg_ParseTuple(args, "O", &type))
         return NULL;

     temptype = NA_getType(type);
     if (temptype == NULL) return NULL;
     typeno = NA_typeObjectToTypeNo(temptype);
     Py_DECREF(temptype);
     if (typeno < 0) {
         PyErr_Format(PyExc_RuntimeError,
                  "_numarray_init: can't get typeno for type");
         return NULL;
     }

Do other functions in "libnumarraymodule.c" need to be documented?




From mbakker at engr.uga.edu  Fri Oct 24 16:33:07 2003
From: mbakker at engr.uga.edu (Mark Bakker)
Date: Fri Oct 24 16:33:07 2003
Subject: [Numpy-discussion] How can I make a Windows distribution like Numeric
Message-ID: <3F99B56E.4010207@engr.uga.edu>

Hello -

Believe it or not but I have written Python code that will mostly be used on 
Windows. I want to make distribution easier by making a nice Window's install 
just like Numeric. Can anbybody fill me in on what software they use to make the 
Windows binary install?

Thanks, Mark




From zbigk at yahoo.com  Fri Oct 24 16:46:14 2003
From: zbigk at yahoo.com (ADV; . Energy Systems & Electrical Design)
Date: Fri Oct 24 16:46:14 2003
Subject: [Numpy-discussion] ADV:  .  Resume for JOB or Service
Message-ID: <E1ADBb3-0003Ra-L1@sc8-sf-mx2.sourceforge.net>


Rich' S 	Resume	

							Santa Clara, CA 95050


  (408) 482-2840          rrsiek at yahoo.com
 



Electrical Designer &  Drafting


Electro-Mechanical Designer & Drafting



Drafting & Design Shopping Centers; grocery stores, hardware stores, restaurants & residential - housing areas, computer business & fast food units installation & testing; 

Energy systems; Solar Panels, Wind Energy, portable & emergency generators; Factory production lines, food & mechanical process machinery Installations & trouble shooting.  

Equipment & production line installations, MCC, Sensors, Wiring, Alarm, Network, Security, Electrical Design & Installations;  Network Sketches, one line diagrams, and "as is" drawings update. 

Customizing Electronic and Electrical Components & Parts, Layouts electronic and electrical schematic, connectors and mechanical detailing. Use CAD, Windows and applications; Programming & Detailing, Production Equipment, Machinery, Conveyors Spiral Elevator, Fast Cannery Transportation, Electronic and Electrical Components, Parts, Schematics & Layouts, Master Control Center, Can Sheet Metal Oven Rebuilding Project, Combustion Remodeling, PD 5,  PLC setup. 

Designing Electric Cars using AutoCAD, Spreadsheet, Basic, dB; electronic and electrical schematic, Layouts, mechanical detailing & redesigning components for manufacturing, Assembly drawings, Customizing Electronic, Mechanical and Electrical Equipment.

Quotes, supply, bids and job estimating. Customers contact, inspection, project mgmt & supervision of electricians & material handling; Commercial & Residential Project; Mgr. for satellite office & shop. 

Commercial, Industrial, Residential, Fire Alarms, Smoke Detectors, Lights, Plugs, Panels, Power Supply, Electro-Solar Installations, Emergency Generators, Transformers, Power Lines, Fire sprinklers design / control, CAD automation. Foreman, Estimator, Designer & CAD Operator (New & "as is" drawings update)

Hands on electrical installation performing, fitting wires & power lines;  Panels, Light, receptacles & Fuse boxes, emergency power supply, parking lighting & post installation; Installing lamps, switches, alarms, plugs, receptacles, fire alarms, smoke detectors, fire & safety installations; Computer & data network wiring; underground installations & conduit layout, bending and mounting; Job Estimating & bid preparation.

Environmental Energy Systems and Green Building Coordinating Programs;  P E C,  C E C,  PG&E training, Solar Living Institute, High Performance Schools, Health Analyzing, using Solar and Wind Energy Friendly Systems, Savings by Design recommendations & new Title 24 Standards - LEED, CEC, AIA & COTE Ratings. 

Electrical & Electrical Drafting, Electrical Design & management, Site Inspection and Quality Control, coordination with General Contractor, Estimating and Supplying, Document Control & Upgrade, daily performance checking & schedule update. 


Electrical Installations & Service

Solar Energy Installations & Service

Electro-Mechanical Assembly & Service

ELECTRICAL PROJECT MANAGER -  COORDINATOR

ELECTRICAL & MAINTENANCE SERVICE

HANDS ON WIRING & INSTALLATION

ELECTRICAL AND MECHANICAL PROJECTS 



Electrical Installations & Service

Solar Energy Installations & Service

Electro-Mechanical Assembly & Service

ELECTRICAL PROJECT MANAGER -  COORDINATOR

ELECTRICAL & MAINTENANCE SERVICE

HANDS ON WIRING & INSTALLATION

ELECTRICAL AND MECHANICAL PROJECTS 

Sun Tracking  double  SOLAR ENERGY



SOLAR ENERGY SYSTEMS

WIND ENERGY SYSTEMS

SUN TRACKING SYSTEMS

SOLAR PALETTE SYSTEMS

FLYWHEEL STORAGE SYSTEMS



Solar Engineer








From gvermeul at grenoble.cnrs.fr  Fri Oct 24 18:40:07 2003
From: gvermeul at grenoble.cnrs.fr (gvermeul at grenoble.cnrs.fr)
Date: Fri Oct 24 18:40:07 2003
Subject: [Numpy-discussion] How can I make a Windows distribution like Numeric
Message-ID: <200310250136.h9P1amB6009732@grenoble.cnrs.fr>

> Hello -
> 
> Believe it or not but I have written Python code that will mostly be used on 
> Windows. I want to make distribution easier by making a nice Window's install 
> just like Numeric. Can anbybody fill me in on what software they use to make the 
> Windows binary install?
> 
> Thanks, Mark
> 
Check out the documentation on distutils that comes with Python.

Gerard


-------------------------------------------------------------
This message was sent using HTTPS service from CNRS Grenoble.
         --->   https://grenoble.cnrs.fr   <---         





From Promoteing at 2911.net  Fri Oct 24 21:06:08 2003
From: Promoteing at 2911.net (Marketing)
Date: Fri Oct 24 21:06:08 2003
Subject: [Numpy-discussion] Marketing Details
Message-ID: <E1ADFaa-0003wy-Rv@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you!  We can send your email message to your 
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you 
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Robert Jones
Sales & Marketing
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database, 
go here www.awayoutofdebtfast.com/dbtremove.htm



From Promoteing at 2911.net  Sun Oct 26 03:09:07 2003
From: Promoteing at 2911.net (Manager)
Date: Sun Oct 26 03:09:07 2003
Subject: [Numpy-discussion] Marketing Strategy
Message-ID: <E1ADifQ-0005KR-R7@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending
out targeted emails, or want to avoid the work of sending out targeted
emails. We will do it for you!  We can send your email message to your
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Dana DeBolt
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database,
go here www.awayoutofdebtfast.com/dbtremove.htm



From rpraca7 at yahoo.com  Sun Oct 26 03:33:09 2003
From: rpraca7 at yahoo.com (Richard's    R E S U M E)
Date: Sun Oct 26 03:33:09 2003
Subject: [Numpy-discussion] Sr.   Mechanical   &   Design     E n g i n e e r
Message-ID: <E1ADj2P-0008Vh-2W@sc8-sf-mx1.sourceforge.net>

Richard's 	Resume	 for Job, 	Consulting or Service


RESUME


                             RICHARD


OBJECTIVE: 			

        	Sr.  MECHANICAL  &  DESIGN    ENGINEER

  Project Mgr, Electro-Mechanical Design, Mfg, Product Development, R&D, CADD

          Tel: ( 408)  309-7006 	rpraca3 at yahoo.com

EXPERIENCE:
08/93-present          Sr. MECHANICAL & DESIGN ENGINEER, CADD Mgr "Mech-Tronic" 
                   


Engineering, Design & Product Development Service; Project Management, Mfg, Tooling, Product Improvement; Developing Working Product, Design and Prototype Production;  Controlling & Managing testing,  redesign, manufacturing documentation preparation;  
and full realization of Task using technical approach, schedules,  and budget to achieve Final Product.  

Selecting vendors and specialist to supply performance  satisfying customers expectation and to create a new, modern product with advanced properties, quality and market desirable working abilities and sellable values.

Preparing propositions & presentations, Review Manufacturing Process and Quality Control, Inspecting standards, Engineering Computations and Technical Improvements,  Supplying and Production Automation. Project Management & Development. 

Preparing technical documentation, calculations, engineering, design, layouts, drawings, 3D and Solid Modeling, development & propositions. Hard Drive Design, testing, balancing, recalculating and redesign. Manufacturing and Assembly Equipment design and build.  Systems Integration.


Tooling and Operations Development, Implementation & Automation for mass production.  Energy, Electric Vehicles and Computerized Transportation System Design & Implement. Solar Panels. Solid Works, Pro-E, CAD Management and Operations, Analyzing, Micro Station, ACAD 10-2002 & LT, Win 3x & 2000', Net, Internet, Softdesk, Structural Design. Network, Security.

Electrical Design & Installations; Commercial, Industrial, Residential, Fire Alarms, Smoke Detectors, Lights, Plugs, Panels, Power Supply,  Electro - Solar Installations, CADD automation. Dynamics, Kinematics, thermodynamics / heat transfer & FEA analyzing.

Manufacturing hydraulic & pneumatic equipment, machinery and control systems, mechanisms, robotics device, precision machine elements.  Inspecting and control manufacturing standards, analyzing stresses and tolerances, selecting materials, engineering computations and technical improvements, documentation, projects development, supplying.

  
Automation, Conveyors, Spiral Elevator, Fast Cannery Transportation, Electronic and Electrical Components, Master Control Center, Sheet Metal Oven Rebuilding Project. Power Systems, UPS.

Automation equipment and machine control using for machines and robotics precision mechanisms motion programming, fluid mechanics, pneumatics systems, mounting and positioning devices, electro-mechanical and vacuum mechanisms, design and analysis of structures, castings, welded frames, mechanical detailing. 

Computers: 

DOS, SUN UNIX, MAC, WP, dB, Lotus, Network, Windows & Applications; MS Project, Excel, Access, Word, PFS, Graphics, CAD / CAM, Excel, Basic, C, Fortran, Analyzes. CADD systems, Algor, VAX, Net.  MCAD, Acad's 2002 & Softdesk, Script, Nastran, Infusoft, LAN, Tektronix, Cadkey,  Lisp, Personal Designer, ACAD / Computer Instructor, Machine Design, Robotics & Automation, WIND, SOLAR, METRIC.



EDUCATION:

Institute for Business & Technology, California
CADD Engineer,  Programming,  Design,  Management


Electro - Mechanical  College
Mechanical Engineering - BSME,   ASEE,  MBA




Open for Travel  *  Salary open *  Permanent  preferred  or Consulting








From edcjones at erols.com  Sun Oct 26 08:41:10 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Sun Oct 26 08:41:10 2003
Subject: [Numpy-discussion] Buglet in NA_set... functions
Message-ID: <3F9BF835.6050903@erols.com>

The source code for NA_set_Float has a "#if HAS_UINT64" while 
NA_set_Int64 doesn't. Neither function works for UInt64 input. It seems 
that the only difference between these two functions is the cast done to 
the input variable "v" when the function is called.




From Promoteing at 2911.net  Sun Oct 26 18:52:21 2003
From: Promoteing at 2911.net (Manager)
Date: Sun Oct 26 18:52:21 2003
Subject: [Numpy-discussion] Marketing Strategy
Message-ID: <E1ADxTU-0001xM-P0@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending
out targeted emails, or want to avoid the work of sending out targeted
emails. We will do it for you!  We can send your email message to your
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Dana DeBolt
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database,
go here www.awayoutofdebtfast.com/dbtremove.htm



From yive96jf at yahoo.com  Mon Oct 27 07:33:09 2003
From: yive96jf at yahoo.com (Isaiah Champagne)
Date: Mon Oct 27 07:33:09 2003
Subject: [Numpy-discussion] INVESTORS: Blue-Chip, Stock-Trading System---77% Return---Automated...cruz
Message-ID: <7q2nx---h4$j15mw1$jowb$ipfp@b7ocg>

Investors: Come see Wall Streets only scale-trading system for blue-chip stocks - MainScale

We DO NOT TOUT INDIVIDUAL STOCKS - This is an automated, stock-trading system for blue-chips only


www.mainscale4u.com/?032335


MainScale started on October 1, 2002

Here are the results our investors have enjoyed over the last year.

Banked return, 1-year: 77.98%

12 consecutive months of profitability

Trades---467
Gainers--442
Losers----15


www.mainscale4u.com/?032335


In fact, the longest period between profitable trades was just 6 days.

In less than 15 minutes a day, you can manage a profitable portfolio that will make you money in any type of market.



www.mainscale4u.com/?032335




No more advertisements, go here: www.mainscale4u.com/nomore.html







































nw u rxdqclfmhk  g nmwznrxsd

From jmiller at stsci.edu  Mon Oct 27 07:47:36 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 27 07:47:36 2003
Subject: [Numpy-discussion] Buglet in NA_set... functions
In-Reply-To: <3F9BF835.6050903@erols.com>
References: <3F9BF835.6050903@erols.com>
Message-ID: <1067269419.1222.19.camel@halloween.stsci.edu>

On Sun, 2003-10-26 at 11:37, Edward C. Jones wrote:
> The source code for NA_set_Float has a "#if HAS_UINT64" while 
> NA_set_Int64 doesn't. Neither function works for UInt64 input. It seems 
> that the only difference between these two functions is the cast done to 
> the input variable "v" when the function is called.
> 
Currently, UInt64 is supported everywhere but under win32/MSVC.  So, on
the standard windows numarray installation,  Uint64 is not supported and
UInt64 arrays cannot be created.  Under these circumstances, the UInt64
paths you're referring to cannot be reached anyway.  Further,  since the
code in question compiles without warnings or errors,  I'd argue that it
*does* work for UInt64 inputs, although they're never going to appear. I
say this because there are indeed sections of numarray code that *don't*
compile without errors for MSVC, hence all UInt64 has been disabled for
MSVC.   Bottom line:  what you're talking about is indeed a little
inconsistent,  but  I don't think it's going to hurt us.

> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From jmiller at stsci.edu  Mon Oct 27 08:04:27 2003
From: jmiller at stsci.edu (Todd Miller)
Date: Mon Oct 27 08:04:27 2003
Subject: [Numpy-discussion] NA_getType needs to be documented
In-Reply-To: <3F9876D9.8040905@erols.com>
References: <3F9876D9.8040905@erols.com>
Message-ID: <1067270527.1223.39.camel@halloween.stsci.edu>

There's a mix of "interface" and "implementation" in libnumarray since
the API jump table mechanism is the only kind of inter-module linkage
used.  Since some of the functions in libnumarray are just there because
they needed to be shared within the implementation, not exported as
public interface, "everything" is never going to be documented. 
However,  specific holes that people point out certainly can be.  I'll
document this one.

Regards,
Todd

On Thu, 2003-10-23 at 20:48, Edward C. Jones wrote:
> "NA_getType" needs to be documented. The following is useful:
> 
>      if (!PyArg_ParseTuple(args, "O", &type))
>          return NULL;
> 
>      temptype = NA_getType(type);
>      if (temptype == NULL) return NULL;
>      typeno = NA_typeObjectToTypeNo(temptype);
>      Py_DECREF(temptype);
>      if (typeno < 0) {
>          PyErr_Format(PyExc_RuntimeError,
>                   "_numarray_init: can't get typeno for type");
>          return NULL;
>      }
> 
> Do other functions in "libnumarraymodule.c" need to be documented?
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21030
(410) 338 - 4576




From Orderlists at 2911.net  Tue Oct 28 11:22:01 2003
From: Orderlists at 2911.net (Manager)
Date: Tue Oct 28 11:22:01 2003
Subject: [Numpy-discussion] Marketing Strategy
Message-ID: <E1AEZO1-00047f-JG@sc8-sf-mx1.sourceforge.net>

Email Marketing is one of the most effective and inexpensive ways to
promote your products and services.

We offer a complete Email Marketing solution with quality service and
the lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses

We can supply targeted email addresses according to your requirements,
which are compiled only on your order. We will customize your customer
email addresses.

* We have millions of email addresses in a wide variety of categories.

2. Send out Targeted Emails for you

If you are worried about any complications or consequences with sending
out targeted emails, or want to avoid the work of sending out targeted
emails. We will do it for you!  We can send your email message to your
targeted customers.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to: http://www.1ccms.com

We will help you get more business opportunities.


Regards!

Dana DeBolt
Customer Support
Support at 1ccms.com
Http://www.1ccms.com

To purge your email address from our database,
go here www.awayoutofdebtfast.com/dbtremove.htm



From rob at hooft.net  Fri Oct 31 05:36:17 2003
From: rob at hooft.net (Rob W.W. Hooft)
Date: Fri Oct 31 05:36:17 2003
Subject: [Numpy-discussion] Problem in LinearAlgebra?
Message-ID: <3FA2617A.4000308@hooft.net>

I am using Polynomial.py from Scientific Python 2.1, together with 
Numeric 17.1.2. This has always served me well, but now we are busy 
upgrading our software, and I am currently porting some code to 
Scientific Python 2.4.1, Numeric 22.0. Suddenly I do no longer manage to 
get proper 2D polynomial fits over 4x4th order. At 5x5 the coefficients 
that come back from LinearAlgebra.linear_least_squares have exploded. In 
the old setup, I easily managed 9x9th order if I needed to, but most of 
the time I'd stop at 6x6th order. Would anyone have any idea how this 
difference can come about? I managed to work around this for the moment 
by using the equivalent code in the fitPolynomial routine that uses 
LinearAlgebra.generalized_inverse (and it doesn't even have problems 
with the same data at 8x8), but this definitely feels not right! I can't 
remember reading anything like this here before.

Together with Konrad Hinsen, I came to the conclusion that the problem 
is not in Scientific Python, so it must be the underlying LinearAlgebra 
code that changed between releases 17 and 22.

I hacked up a simplified example. Not sure whether it is the most simple 
case, but this resembles what I have in my code, and I'm quite sure it 
worked with Numeric 17.x, but currently it is horrible over order (4,4):

--------------------------------------
import Numeric

def func(x,y):
     return x+0.1*x**2+0.01*x**4+0.002*x**6+0.03*x*y+0.001*x**4*y**5

x=[]
y=[]
z=[]
for dx in Numeric.arange(0,1,0.01):
     for dy in Numeric.arange(0,1,0.01):
         x.append(dx)
         y.append(dy)
         z.append(func(dx,dy))

from Scientific.Functions import Polynomial
data=Numeric.transpose([x,y])
z=Numeric.array(z)
for i in range(10):
     print data[i],z[i]
pol=Polynomial.fitPolynomial((4,4),data,z)
print pol.coeff
------------------------------------
for 4,4 this prints:
[[  1.84845529e-05  -7.60502772e-13   2.71314749e-12  -3.66731796e-12
          1.66977148e-12]
  [  9.99422967e-01   3.00000000e-02  -3.26346097e-11   4.42406519e-11
         -2.01549767e-11]
  [  1.03899464e-01  -3.19668064e-11   1.14721790e-10  -1.55489826e-10
          7.08425891e-11]
  [ -9.40275000e-03   4.28456838e-11  -1.53705205e-10   2.08279772e-10
         -9.48840470e-11]
  [  1.80352695e-02  -1.10999843e-04   8.00662570e-04  -2.17266676e-03
          2.47500004e-03]]

for 5,5:

[[ -2.25705839e+03   6.69051337e+02  -6.60470163e+03   6.66572425e+03
         -8.67897022e+02   1.83974866e+03]
  [ -2.58646837e+02  -2.46554689e+03   1.15965805e+03   7.01089888e+03
         -2.11395436e+03   2.10884815e+03]
  [  3.93307499e+03   4.34484805e+02  -4.84080392e+03   5.90375330e+03
          1.16798049e+03  -4.14163933e+03]
  [  1.62814750e+03   2.08717457e+03   1.15870693e+03  -3.37838057e+03
          3.49821689e+03   5.80572585e+03]
  [  4.54127557e+02  -1.56645524e+03   4.58997025e+00   1.69772635e+03
         -1.37751039e+03  -7.59726558e+02]
  [  2.37878239e+03   9.43032094e+02   8.58518644e+02  -8.35846339e+03
         -5.55845668e+02   1.87502761e+03]]

Which is clearly wrong.

I appreciate any help!

Regards,

Rob

-- 
Rob W.W. Hooft  ||  rob at hooft.net  ||  http://www.hooft.net/people/rob/




From edcjones at erols.com  Fri Oct 31 18:16:22 2003
From: edcjones at erols.com (Edward C. Jones)
Date: Fri Oct 31 18:16:22 2003
Subject: [Numpy-discussion] gcc compile / link questions
Message-ID: <3FA31683.10703@erols.com>

I compile and link Python extension modules using the script

gcc -fPIC -g -I/usr/local/include/python2.3 \
  -Wall -Wstrict-prototypes -c mymodule.c
g++ -shared mymodule.o -L/usr/local/lib -o mymodule.so

It works for me but it isn't pretty. Is there a better way to write it?

Gcc finds all the libraries that need to be linked in. For example,
"/usr/local/lib/python2.3/site-packages/numarray/libnumarray.so". How 
does gcc do this?

I created a .so file "utilities.so" that contains some C functions that 
are called in mymodule.c but are not visible from Python. Both 
"utilities.c" and "mymodule.c" use numarray. What changes do I make in 
the script above? Must I use the nasty "libnumarray_UNIQUE_SYMBOL" trick?

What is a script for creating "utilities.a" using gcc? How do I change 
the script above to include "utilities.a"?