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

Re: [Numpy-discussion] numarray on Cygwin

[Jochen <jo...@un...>]

On Tue, 07 May 2002 08:57:00 -0400 Todd Miller wrote:

Todd> Jochen K=FCpper wrote:

>> I am trying to run numarray on Cygwin.
>> (Where Numeric seems to work fine.)
>>=20
>> In order to compile it I had to change the use of round to rint, as
>> Cygwin's C library (newlib) doesn't have round.  The patch is
>> attached.

Todd> Trying to call a PyCObject is a symptom of an inconsistent
Todd> installation.

That was easy.  I am not sure why a=20
,----
| python setup.py build --force
| python setup.py install --force
`----
didn't do it "right" automatically (it definitely /should/), but
deleting everyting in site-packages and reinstalling works.


The remaining question is how to deal with round:
a) Use rint instead of round everywhere.
b) We use rint but make sure we are using the correct rounding mode.
c) We write our own round function using floor or ceil and use that on
   Cygwin.
d) We use rint on Cygwin, round everywhere else.


Greetings,
Jochen
--=20
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E

Re: [Numpy-discussion] numarray on Cygwin

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

Jochen Küpper wrote:

>I am trying to run numarray on Cygwin.
>(Where Numeric seems to work fine.)
>
>In order to compile it I had to change the use of round to rint, as
>Cygwin's C library (newlib) doesn't have round.  The patch is
>attached.
>
>When I use it I don't get far, though:
>,----
>| > python
>| Python 2.2 (#1, Dec 31 2001, 15:21:18) 
>| [GCC 2.95.3-5 (cygwin special)] on cygwin
>| Type "help", "copyright", "credits" or "license" for more information.
>| >>> import numarray as na
>| >>> x = na.array([1.0, 2.0])
>| >>> x
>| Traceback (most recent call last):
>|   File "<stdin>", line 1, in ?
>|   File "/usr/lib/python2.2/site-packages/numarray/numarray.py", line 591, in __repr__
>|     MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ', ', 1)
>|   File "/usr/lib/python2.2/site-packages/numarray/arrayprint.py", line 86, in array2string
>|     format, item_length = _floatFormat(data, precision, suppress_small)
>|   File "/usr/lib/python2.2/site-packages/numarray/arrayprint.py", line 140, in _floatFormat
>|     non_zero = numarray.abs(numarray.compress(numarray.not_equal(data, 0), data))
>|   File "/usr/lib/python2.2/site-packages/numarray/ufunc.py", line 474, in __call__
>|     cfunc, ufargs, scalar)
>|   File "/usr/lib/python2.2/site-packages/numarray/ufunc.py", line 312, in _doit
>|     apply(cfunc, ufargs)
>| TypeError: 'PyCObject' object is not callable
>| >>>
>`----
>If I print out the type of cfunc down in _doit, I get (the expected)
>,----
>| <type 'PyCObject'>
>`----
>
>Any ideas, probably some hints how to proceed?
>
Hi Jochen,

Trying to call a PyCObject is a symptom of an inconsistent installation. 
  Extension functions stopped being passed around as PyCObjects in 
numarray-0.3.  Instead, I created a new C-type called CFunc which binds 
an "extension function implementation" to the correct generic wrapper. 
 An added benefit was that CFuncs are directly callable as python 
functions, whereas PyCObjects were not.

The repr of a CFunc looks more like:

 >>> import _ufuncInt32
 >>> _ufuncInt32.functionDict[_ufuncInt32.functionDict.keys()[0]]
<cfunc 'rshift_Int32_reduce' at 4019ffec check-self:0 align:1  io:(1, 1)>

So, it appears that your c-extensions are not yet updated to CFuncs, but 
your numarray python code is updated to CFuncs.  

 I suggest deleting  your numarray installation and re-installing. 

Todd

>
>Greetings,
>Jochen
>
>
>------------------------------------------------------------------------
>
>? Lib/ChangeLog
>? Lib/numinclude.py
>Index: Include/numarray/ChangeLog
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Include/numarray/ChangeLog,v
>retrieving revision 1.1
>diff -u -r1.1 ChangeLog
>--- Include/numarray/ChangeLog	22 Apr 2002 20:33:16 -0000	1.1
>+++ Include/numarray/ChangeLog	6 May 2002 22:32:43 -0000
>@@ -1,8 +1,18 @@
>+2002-05-06  Jochen Küpper  <jo...@un...>
>+
>+	* numcomplex.h (NUM_CROUND): Use rint instead of round.  The latter is
>+	not available on all systems, namely Cygwin.
>+
> 2002-04-10  Jochen Küpper  <jo...@un...>
> 
> 	* ndarrayinfo.h: Change NDInfo->strides to NDInfo->stride for
> 	consistency.  Adopt all sources accordingly.
> 
>-	* genapi.py (bodystring): Do not include emacs' Local Variables
>-	section into gnerated files.
>+	* genapi.py (bodystring): Do not include emacs' Local Variables section
>+	into gnerated files.
>+
> 
>+	* Local Variables:
>+	* mode: auto-fill
>+	* fill-column: 79
>+	* End:
>Index: Include/numarray/numcomplex.h
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Include/numarray/numcomplex.h,v
>retrieving revision 1.5
>diff -u -r1.5 numcomplex.h
>--- Include/numarray/numcomplex.h	30 Apr 2002 17:29:43 -0000	1.5
>+++ Include/numarray/numcomplex.h	6 May 2002 22:32:43 -0000
>@@ -228,7 +228,7 @@
> #define NUM_CCEIL(p, s) (s).r = ceil((p).r); (s).i = ceil((p).i);
> 
> #define NUM_CFABS(p, s)  (s).r = fabs((p).r);  (s).i = fabs((p).i);
>-#define NUM_CROUND(p, s) (s).r = round((p).r); (s).i = round((p).i);
>+#define NUM_CROUND(p, s) (s).r = rint((p).r); (s).i = rint((p).i);
> #define NUM_CHYPOT(p, q, s) { Complex64 t;                                    \
>                               NUM_CSQR(p, s);  NUM_CSQR(q, t);                \
>                               NUM_CADD(s, t, s);                              \
>Index: Lib/codegenerator.py
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Lib/codegenerator.py,v
>retrieving revision 1.22
>diff -u -r1.22 codegenerator.py
>--- Lib/codegenerator.py	3 May 2002 19:14:06 -0000	1.22
>+++ Lib/codegenerator.py	6 May 2002 22:32:44 -0000
>@@ -1593,7 +1593,7 @@
> ["minimum", 2, 1, (function_td, "ufminimum"), generic_operator_sigs, opt_minmax_decl],
> 
> ["fabs",    1, 1, (function_td, "fabs"),  generic_mathfunction_sigs, ""],
>-["around",  1, 1, (function_td, "round"), generic_mathfunction_sigs, ""],
>+["around",  1, 1, (function_td, "rint"), generic_mathfunction_sigs, ""],
> ["hypot",   2, 1, (function_td, "hypot"), generic_mathfunction_sigs, ""],
> 
> # Complex ufuncs
>Index: Src/_ufuncBoolmodule.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncBoolmodule.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncBoolmodule.c
>--- Src/_ufuncBoolmodule.c	29 Apr 2002 21:39:50 -0000	1.8
>+++ Src/_ufuncBoolmodule.c	6 May 2002 22:32:45 -0000
>@@ -2365,7 +2365,7 @@
>     Float32 *tout = (Float32 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>Index: Src/_ufuncFloat32module.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncFloat32module.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncFloat32module.c
>--- Src/_ufuncFloat32module.c	29 Apr 2002 21:39:50 -0000	1.8
>+++ Src/_ufuncFloat32module.c	6 May 2002 22:32:45 -0000
>@@ -1773,7 +1773,7 @@
>     Float32 *tout = (Float32 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>Index: Src/_ufuncFloat64module.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncFloat64module.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncFloat64module.c
>--- Src/_ufuncFloat64module.c	29 Apr 2002 21:39:50 -0000	1.8
>+++ Src/_ufuncFloat64module.c	6 May 2002 22:32:45 -0000
>@@ -1773,7 +1773,7 @@
>     Float64 *tout = (Float64 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>Index: Src/_ufuncInt16module.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncInt16module.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncInt16module.c
>--- Src/_ufuncInt16module.c	29 Apr 2002 21:39:51 -0000	1.8
>+++ Src/_ufuncInt16module.c	6 May 2002 22:32:45 -0000
>@@ -2254,7 +2254,7 @@
>     Float32 *tout = (Float32 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>Index: Src/_ufuncInt32module.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncInt32module.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncInt32module.c
>--- Src/_ufuncInt32module.c	29 Apr 2002 21:39:51 -0000	1.8
>+++ Src/_ufuncInt32module.c	6 May 2002 22:32:45 -0000
>@@ -2254,7 +2254,7 @@
>     Float32 *tout = (Float32 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>Index: Src/_ufuncInt8module.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncInt8module.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncInt8module.c
>--- Src/_ufuncInt8module.c	29 Apr 2002 21:39:51 -0000	1.8
>+++ Src/_ufuncInt8module.c	6 May 2002 22:32:45 -0000
>@@ -2254,7 +2254,7 @@
>     Float32 *tout = (Float32 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>Index: Src/_ufuncUInt16module.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncUInt16module.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncUInt16module.c
>--- Src/_ufuncUInt16module.c	29 Apr 2002 21:39:51 -0000	1.8
>+++ Src/_ufuncUInt16module.c	6 May 2002 22:32:45 -0000
>@@ -2249,7 +2249,7 @@
>     Float32 *tout = (Float32 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>Index: Src/_ufuncUInt8module.c
>===================================================================
>RCS file: /cvsroot/numpy/numarray/Src/_ufuncUInt8module.c,v
>retrieving revision 1.8
>diff -u -r1.8 _ufuncUInt8module.c
>--- Src/_ufuncUInt8module.c	29 Apr 2002 21:39:51 -0000	1.8
>+++ Src/_ufuncUInt8module.c	6 May 2002 22:32:45 -0000
>@@ -2249,7 +2249,7 @@
>     Float32 *tout = (Float32 *) buffers[1];
>     
>     for (i=0; i<niter; i++, tin++, tout++) {
>-        *tout = round(*tin);
>+        *tout = rint(*tin);
>     }
>     return 0;
> }
>
> numarray.diff
>
> Content-Type:
>
> text/x-patch
> Content-Encoding:
>
> quoted-printable
>
>


-- 
Todd Miller 			jm...@st...
STSCI / SSG			(410) 338 4576

[Numpy-discussion] numarray on Cygwin

[Jochen <jo...@un...>]

I am trying to run numarray on Cygwin.
(Where Numeric seems to work fine.)

In order to compile it I had to change the use of round to rint, as
Cygwin's C library (newlib) doesn't have round.  The patch is
attached.

When I use it I don't get far, though:
,----
| > python
| Python 2.2 (#1, Dec 31 2001, 15:21:18) 
| [GCC 2.95.3-5 (cygwin special)] on cygwin
| Type "help", "copyright", "credits" or "license" for more information.
| >>> import numarray as na
| >>> x = na.array([1.0, 2.0])
| >>> x
| Traceback (most recent call last):
|   File "<stdin>", line 1, in ?
|   File "/usr/lib/python2.2/site-packages/numarray/numarray.py", line 591, in __repr__
|     MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ', ', 1)
|   File "/usr/lib/python2.2/site-packages/numarray/arrayprint.py", line 86, in array2string
|     format, item_length = _floatFormat(data, precision, suppress_small)
|   File "/usr/lib/python2.2/site-packages/numarray/arrayprint.py", line 140, in _floatFormat
|     non_zero = numarray.abs(numarray.compress(numarray.not_equal(data, 0), data))
|   File "/usr/lib/python2.2/site-packages/numarray/ufunc.py", line 474, in __call__
|     cfunc, ufargs, scalar)
|   File "/usr/lib/python2.2/site-packages/numarray/ufunc.py", line 312, in _doit
|     apply(cfunc, ufargs)
| TypeError: 'PyCObject' object is not callable
| >>>
`----
If I print out the type of cfunc down in _doit, I get (the expected)
,----
| <type 'PyCObject'>
`----

Any ideas, probably some hints how to proceed?

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E

[Numpy-discussion] import Numeric fails with user-supplied __import__?

[Mr. B. <to...@il...>]

Hey Folks,

using the recently released python 2.1.3 with version 20.3 of the
Numeric package, we are getting this behavior:

(tommy@mace)/u0/tommy$ python2
Python 2.1.3 (#1, Apr 22 2002, 16:14:11) [C] on irix6
Type "copyright", "credits" or "license" for more information.
>>> import ihooks
>>> ihooks.install()
>>> import Numeric
Segmentation fault

this is happening on both irix and linux.  I checked the release notes 
for Numeric 20.1 but didn't see any mention of import bugs being
fixed.  a little bit of investigation shows that it isn't even ihooks
that causes this, it is any user-supplied __import__:

blah.py:
import __builtin__

class blah:
    def __init__( self ):
        self.real_importer = __builtin__.__import__
        __builtin__.__import__ = self.my_import

    def my_import( self, name, globs={}, locs={}, fromlist=[] ):
        return self.real_importer( name, globs, locs, fromlist )


_blah = blah()

859:tpelle@parro > python2
Python 2.1.3 (#1, Apr 19 2002, 21:22:42)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2
Type "copyright", "credits" or "license" for more information.
 >>> import blah
 >>> import Numeric
Segmentation fault (core dumped)


anyone out there seen this before?  any guess if its Numeric's problem 
or perhaps a bug deeper down in python's import architecture?

any and all clues appreciated, thanks!

Re: [Numpy-discussion] two tricky operations

[Pete S. <pe...@sh...>]

> def twod(n,m):
>     a = zeros((n,m,2))
>     b = arange(n*m)
>     a[:,:,0] = transpose(reshape(b % n, (m,n)))
>     a[:,:,1] = reshape(b % m, (n,m))
>     return a

eric has sent me a great version off the list:

def other_twod(n,m):
	q = indices((n, m)
	return transpose(q)[:,:,::-1]


> It's not clear to me what you mean here.  If you have an array with
> shape (n,m,3) and want to get (n*m,3), just use reshape(a,(n*m,3)).
> Maybe you mean something more complicated than that?

no, this is exactly what i meant. in hindsight i realize i already knew 
how to do this. owell, and thanks for the answers :]

Re: [Numpy-discussion] two tricky operations

[Rick W. <rl...@st...>]

Since nobody else has replied to this yet, I'll take a crack at it.

On Thu, 2 May 2002, Pete Shinners wrote:

> help, i need help formatting some data in Numeric arrays. i can't quite
> seem to make it happen. here they come... (beware)
>
> 1: i want to create a simple 3d array, so that accessing it with any two
> indices gives me the same result as those two indices..
> 	myarray[1,2] == 1,2
> 	myarray[4,4] == 4,4
> i would assume this just involves mixing two arange()'s together, but i
> can't seem to get them meshed together correctly. actually, this is
> something i think i'd want quite a bit, it'd be real real nice if arange
> could take multiple axes. :]  i thought this might be a good
> "fromfunction" situation, but i couldn't get that to go either.

This works.  I don't know whether it is optimal, though I think it
isn't bad.  Note that the returned values are 2-element Numeric arrays,
not tuples.  Seems to me that arrays are a lot more usable as return
values.

def twod(n,m):
    a = zeros((n,m,2))
    b = arange(n*m)
    a[:,:,0] = transpose(reshape(b % n, (m,n)))
    a[:,:,1] = reshape(b % m, (n,m))
    return a

> 2: i have a 3d array with image data (RGBs). i want to flatten only the
> first two dimensions so i have an array of RGB values. this one's got me
> completely stumped. i'm hoping there's just some function i'm not seeing
> in the docs, but i'd be just as happy with a bit of Numeric magic.

It's not clear to me what you mean here.  If you have an array with
shape (n,m,3) and want to get (n*m,3), just use reshape(a,(n*m,3)).
Maybe you mean something more complicated than that?
					Rick

------------------------------------------------------------------
Richard L. White    rl...@st...    http://sundog.stsci.edu/rick/
Space Telescope Science Institute
Baltimore, MD

[Numpy-discussion] two tricky operations

[Pete S. <pe...@sh...>]

help, i need help formatting some data in Numeric arrays. i can't quite 
seem to make it happen. here they come... (beware)


1: i want to create a simple 3d array, so that accessing it with any two 
indices gives me the same result as those two indices..
	myarray[1,2] == 1,2
	myarray[4,4] == 4,4
i would assume this just involves mixing two arange()'s together, but i 
can't seem to get them meshed together correctly. actually, this is 
something i think i'd want quite a bit, it'd be real real nice if arange 
could take multiple axes. :]  i thought this might be a good 
"fromfunction" situation, but i couldn't get that to go either.



2: i have a 3d array with image data (RGBs). i want to flatten only the 
first two dimensions so i have an array of RGB values. this one's got me 
completely stumped. i'm hoping there's just some function i'm not seeing 
in the docs, but i'd be just as happy with a bit of Numeric magic.



thanks, please, and all that good stuff!

Re: [Numpy-discussion] Multiple Linear Regression?

[Tim C. <tc...@op...>]

Jasper Phillips wrote:
> 
> I'm helping my wife with programming for her economics thesis, which needs
> to calculate a "Multiple Linear Regression" on her data.
> 
> Does anyone know of any (preferably though not necesarrily free) software
> that can do this? I'm working in Python, but not limited to it as I
> can relatively freely access other languages.

Jasper,

Use R (a free implementation of S). See http://www.r-project.org

If you are managing your data in Python and NumPy, you can "embed" R in
Python
and transparently send data to it using Walter Moreira's wonderful RPy
module - 
see http://rpy.sf.net

Tim C

RE: [Numpy-discussion] unsigned short support in NumPy

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

> Sebastian Haase writes:

> 
> Hi all,
> I'm _very_ new to NumPy.
> I was interested in using it for our project, where we acquire 
> data from a 
> CCD camera.
> 
> The Problem:  Each pixel in the image is a 16 bit gray value.
>              What I read in the documentation - there is only 8 
> bit (unsigned 
> integer) support in numpy (or should I say numericarray)
> 
> Are there plans to add a "unsigned short" (16 bit) support .
> How much effort would that be.
> 
There is a reimplemenation of Numeric that we are doing that does
support unsigned ints (Unsigned Int8, Unsigned Int16 for now).
The project is not mature, but a lot of basic cabability exists
now. You'll have to look it over to judge if it is usable 
for you now. The new version is called numarray
( http://stsdas.stsci.edu/numarray )

(btw, we acquire data from CCD cameras as well ;-) 

Perry

[Numpy-discussion] testing Numeric.array([0])

[Rick R. <ri...@bi...>]

Should Numeric.array([0]) test false?  This seems counterintuitive, and
is not the case for the regular python array module.

This recently caused a subtle bug for me when I wanted to find the
indices of an array that met a condition.  If only the first element met
the condition, the result was array([0]) -- a non-empty result that
evaluated false.

If this is the intended behavior, can someone tell me the reason?

thanks,
Rick

[Numpy-discussion] unsigned short support in NumPy

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

Hi all,
I'm _very_ new to NumPy.
I was interested in using it for our project, where we acquire data from a 
CCD camera.

The Problem:  Each pixel in the image is a 16 bit gray value.
             What I read in the documentation - there is only 8 bit (unsigned 
integer) support in numpy (or should I say numericarray)

Are there plans to add a "unsigned short" (16 bit) support .
How much effort would that be.

Regards,
Sebastian Haase


-- 
                                _\\|//_
                               (' O-O ')
------------------------------ooO-(_)-Ooo--------------------------------------
Sebastian Haase
University of California, San Francisco
(415)502-4316

[Numpy-discussion] ANN: Numarray-0.3.3

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

Numarray 0.3.3
---------------------------------
Numarray is an array processing package designed to efficiently 
manipulate large multi-dimensional arrays.  Numarray is modelled after 
Numeric and features c-code generated from python template scripts, the 
capacity to operate directly on arrays in files, and improved type 
promotions.

Numarray-0.3.3 features improved support for arrays of complex numbers, 
re-implementing complex types using generated code.  In  addition to 
being faster, the new complex ufuncs are better integrated with the 
numarray type system, so operations between numarrays and complex 
scalars now work properly.  This release also fixes a problem 
experienced by RedHat Linux users installing numarray from source.

WHERE
-----------
Numarray-0.3.3 windows executable installers and source code tar ball is 
here:

http://sourceforge.net/project/showfiles.php?group_id=1369

Numarray is hosted by Source Forge in the same project which hosts Numeric:

http://sourceforge.net/projects/numpy/

The web page for Numarray information is at:

http://stsdas.stsci.edu/numarray/index.html

Trackers for Numarray Bugs, Feature Requests, Support, and Patches are at
the Source Forge project for NumPy at:

http://sourceforge.net/tracker/?group_id=1369

REQUIREMENTS
--------------------------

numarray-0.3.3 requires Python 2.0 or greater.


AUTHORS, LICENSE
------------------------------

Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC
Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science
Institute.  Thanks go to Jochen Kupper of the University of North
Carolina for his work on Numarray and for porting the Numarray manual
to TeX format.

Numarray is made available under a BSD-style License.  See
LICENSE.txt in the source distribution for details.

-- 
Todd Miller             jm...@st...

[Numpy-discussion] kdfio, 1.1.1

[<ca...@ki...>]

hy,
here is the url last version of kdfio a khoros/cantata kdf file importer:
nothing special, but it seems  working now, at least for me;-)
You can find it at:

http://kdfio.sourceforge.net

This is my (very) small contribution to the numerical python:
inside i plugged a way to modularize the code (and writing some skeleton
semi-automatically) that could speed up a litte bit writing new code.
Before to give a full announcement on sourceforge i will wait a little
bit, just to see if there are no bugs around.
Fell free to use/change/make what you want,

thanks to all,
antonio cavallo

ps. khoros is available at http://www.khoral.com and it is not a free
program: there is just a free student version.

Re: [Numpy-discussion] Multiple Linear Regression?

[Alexandre <Ale...@lo...>]

On Mon, Apr 29, 2002 at 03:19:37PM +0200, Alexandre wrote:

> I'm helping my wife with her History PhD, and have to deal with similar
> stuff. I found R to be a very useful environment for statistical
> computations. R is a free software clone of S-plus, which is to statistics
> what Matlab is to linear algebra and automation. 


Woops, I forgot to add a couple of URLs:

The R project website 
 http://www.r-project.org/
The Comprehensive R Archive Network (CRAN)
 http://cran.r-project.org/
Using R from Python
 http://rpy.sourceforge.net/
Using R from Python and Python from R (coding R extensions in Python)
 http://www.omegahat.org/RSPython/

Cheers,

Alexandre Fayolle
-- 
LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org
Narval, the first software agent available as free software (GPL).

Re: [Numpy-discussion] Multiple Linear Regression?

[Alexandre <Ale...@lo...>]

On Mon, Apr 29, 2002 at 03:13:44AM -0700, Jasper Phillips wrote:
> I'm helping my wife with programming for her economics thesis, which needs
> to calculate a "Multiple Linear Regression" on her data.
> 
> Does anyone know of any (preferably though not necesarrily free) software
> that can do this? I'm working in Python, but not limited to it as I
> can relatively freely access other languages.
> 
> I'm still looking for a library written in Python, but haven't had any luck.
> 

I'm helping my wife with her History PhD, and have to deal with similar
stuff. I found R to be a very useful environment for statistical
computations. R is a free software clone of S-plus, which is to statistics
what Matlab is to linear algebra and automation. 

Pros: 
 - programming environment, with a high level programming language
 - extensive statistical and linalg library (using C and FORTRAN code)
 - lots of third party code available, covering a very wide range of
   situations
 - Python bindings available if you don't want to learn the Scheme-like
   language
 - Tons of documentation available
 - Excellent support through the mailing lists
 - GPL'd
 - Tons of way to import data (ranging from CSV files to ODBC queries)
 - 2 printed books available, at Springer Verlag
 - postscript, png, wmf, X outputs, with precise control of the layout
   of the graphs and figures available for a nice colourful thesis

Cons:
 - the language can be a bit weird at times (it took me some time to get
   used to '.' being used instead of '_' and vice versa in the scoping
   and variable naming), but you can use Python to script R, thanks to
   RPython
 - it's quite a big piece of code, with a rather steep learning curve
   and you need time to get inside it
 - the documentation is aimed at professional statisticians. I had to
   dig back in my statistics courses and to buy a couple of books on
   that topic for the software to become really useful. Asking newbie
   statistician questions on the r-help mailing list is off-topic
 - the springer verlag books are very expensive (Modern Applied
   Statistics with S-plus costs something like 70 euros), but they are
   great

So you have a powerful tool available at your fingertips, designed to do
precisely what you need. I think it's worth taking the time to look at
it carefully. The more I get to understand the topic, the more ideas I
get for new ways of exploring the data of my wife's PhD. 

 
Alexandre Fayolle
-- 
LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr  http://www.logilab.org
Narval, the first software agent available as free software (GPL).

Re: [Numpy-discussion] Multiple Linear Regression?

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

Jasper Phillips <ja...@pe...> writes:

> I'm still looking for a library written in Python, but haven't had any luck.

Numerical Python has all the basic stuff, but you need to read in and
arrange the data yourself. All linear regression problems ultimately
become least-squares problems for a system of linear equations, which
can be solved using LinearAlgebra.linear_least_squares.

Konrad.

[Numpy-discussion] Multiple Linear Regression?

[Jasper P. <ja...@pe...>]

I'm helping my wife with programming for her economics thesis, which needs
to calculate a "Multiple Linear Regression" on her data.

Does anyone know of any (preferably though not necesarrily free) software
that can do this? I'm working in Python, but not limited to it as I
can relatively freely access other languages.

I'm still looking for a library written in Python, but haven't had any luck.

My second thought was Matlab, but looking over the Matlab website, I couldn't
find anything like this by a name I recognize. It looks like I might be able
to construct something out of a combination of Sparse Matrices and Linear
Regesstion, or perhaps the stuff for overdetermined Linear Equations?

Another option may be LAPACK routines, but I'm not familiar with those.

Does anyone here have any experience with this kind of stuff? Is there a
better place to ask? I'm about ready to take a shot at writing something
myself, but I'd really rather avoid this if it's been done before.

-Jasper

Re: [Numpy-discussion] Graphs in numarray?

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

Magnus Lie Hetland <ma...@he...> writes:

> (Any idea where the "kj" prefix comes from, by the way?)

I asked Aaron Watter about this. The answer: k and j are the initials
of his children.

Konrad.

RE: [Numpy-discussion] Non-numeric arrays?

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

[I see Todd has already answered this, the following might add
a little more detail]

> -----Original Message-----
> From: num...@li...
> [mailto:num...@li...]On Behalf Of Magnus
> Lie Hetland
> Sent: Thursday, April 25, 2002 10:42 AM
> To: Numpy-discussion
> Subject: [Numpy-discussion] Non-numeric arrays?
> 
> 
> I can't find this in the docs (although I've heard it's mentioned
> there)... Is support for non-numeric arrays (such as character arrays
> or object pointer arrays) as in Numeric planned for numarray? (Perhaps
> even supported? My version might not be themost recent...)
> 
Yes, in fact there is a character array class included with
numarray (but not documented, I believe. For the moment,
you'll have to deal with the source. We developed it for use
with our I/O library but it seemed to be of general enough
use to include with numarray.

We also plan to support arrays of Python objects. There are
various ways that this could be done and we ought to discuss
how it should be done (perhaps multiple ways). But the 
underlying machinery certainly will support it.

> And what about subclasses of numeric types?
> 
> E.g:
> 
> # numarray
> >>> class foo(int): pass
> >>> a = array(map(foo, xrange(10)))
> [...]
> TypeError: Expecting a python numeric type, got a foo
> 
> # Numeric
> >>> class foo(int): pass
> >>> a = array(map(foo, xrange(10)))
> >>> tupe(a[0])
> <type 'int'>
> 
> Neither behaviour seems very helpful -- I guess numarray's is
> cleaner... (Although in this case I think an object array could have
> been nice...)
> 
We haven't had much time to think about how we deal with
numeric subclasses. Certainly one would not use these
for efficiency, I can't see any simple way of making such
things go fast. But it may be possible to have such things 
work with numarray ufuncs and other numeric operations
in some automatic way. I'd have to think about that. It's
not high on the priority list at the moment. (Speaking of
which I may post in a few days).

Thanks, Perry
> 

Re: [Numpy-discussion] Non-numeric arrays?

[Magnus L. H. <ma...@he...>]

Magnus Lie Hetland <ma...@he...>:
[snip]

Just a quick explanation for why I'm interested in this...

I've got a two-dimensional array of ints (or bytes, actually), that I
would like to convert to a delimited string (e.g. comma-separated).

This works in Numeric:

>>> from string import letters
>>> alphabet = array(letters)
>>> data = arange(24) # E.g...
>>> data.shape = 6, 4
>>> fields = sum(take(alphabet, data), 1)
>>> ','.join(fields)
'abcd,efgh,ijkl,mnop,qrst,uvwx'

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

Re: [Numpy-discussion] Non-numeric arrays?

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

Magnus Lie Hetland wrote:

>I can't find this in the docs (although I've heard it's mentioned
>there)... Is support for non-numeric arrays (such as character arrays
>or object pointer arrays) as in Numeric planned for numarray? (Perhaps
>
Check out chararray for character arrays.  
Check out recarray for arrays of fixed length structs.  
To make your own non-numeric arrays, subclass NDArray.

>
>even supported? My version might not be themost recent...)
>
>And what about subclasses of numeric types?
>
>E.g:
>
># numarray
>
>>>>class foo(int): pass
>>>>a = array(map(foo, xrange(10)))
>>>>
>[...]
>TypeError: Expecting a python numeric type, got a foo
>
># Numeric
>
>>>>class foo(int): pass
>>>>a = array(map(foo, xrange(10)))
>>>>tupe(a[0])
>>>>
><type 'int'>
>
>Neither behaviour seems very helpful -- I guess numarray's is
>cleaner... (Although in this case I think an object array could have
>been nice...)
>
Object arrays fall into the *eventually* category:  planned but not 
imminent.

>
>
>--
>Magnus Lie Hetland                                  The Anygui Project
>http://hetland.org                                  http://anygui.org
>
>_______________________________________________
>Numpy-discussion mailing list
>Num...@li...
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
Todd

-- 
Todd Miller 			jm...@st...
STSCI / SSG			(410) 338 4576

[Numpy-discussion] Non-numeric arrays?

[Magnus L. H. <ma...@he...>]

I can't find this in the docs (although I've heard it's mentioned
there)... Is support for non-numeric arrays (such as character arrays
or object pointer arrays) as in Numeric planned for numarray? (Perhaps
even supported? My version might not be themost recent...)

And what about subclasses of numeric types?

E.g:

# numarray
>>> class foo(int): pass
>>> a = array(map(foo, xrange(10)))
[...]
TypeError: Expecting a python numeric type, got a foo

# Numeric
>>> class foo(int): pass
>>> a = array(map(foo, xrange(10)))
>>> tupe(a[0])
<type 'int'>

Neither behaviour seems very helpful -- I guess numarray's is
cleaner... (Although in this case I think an object array could have
been nice...)

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

Re: [Numpy-discussion] Graphs in numarray?

[Magnus L. H. <ma...@he...>]

Morten Kjeldgaard <mo...@im...>:
>
> 
> > simple dict-based stuff -- more performance is needed). kjbuckets
> > looks like a nice alternative, as does the Boost Graph Library (not
> 
> Kjbuckets is *very* nice indeed.

Yes, I guess it is. But the project doesn't seem very active...

> It is a compact and very fast implementation. I don't see why you'd
> want to wrap this functionality into NumPy, which has a very
> well-defined scope and an efficient implentation.  It would be a
> shame to bloat it with something which is discretely different.

Yes, I guess you're right. There is no point in adding this sort of
thing to numarray. My motivation for using numarray in my
implementations was simply that it would mean that the necessery tools
would be (or might be in the future ;) available in the standard
distribution.

> I have modified kjbuckets so that it compiles and works with Python 2.x. 
> You can pick it up at 
> 
> ftp://xray.imsb.au.dk 
> /pub/birdwash/packages/Python2.1/SRPMS/python-kjbuckets-2.2-7.src.rpm
> 
> Just do "rpm --rebuild" on it.
> 
> I sent the patch to the original author, but it appears he is no longer 
> maintaining it. Never mind, it works great.

Well... I do sort of mind... I'm a bit wary of using unmaintained
software. Not that I would never do it or anything... But I think it
would be a bonus to use stuff that is being actively maintained and
developed. But I guess I'll take another look at it.

(Any idea where the "kj" prefix comes from, by the way?)

> /Morten

--
Magnus Lie Hetland                                  The Anygui Project
http://hetland.org                                  http://anygui.org

Re: [Numpy-discussion] Graphs in numarray?

[Morten K. <mo...@im...>]

> simple dict-based stuff -- more performance is needed). kjbuckets
> looks like a nice alternative, as does the Boost Graph Library (not

Kjbuckets is *very* nice indeed. It is a compact and very fast
implementation. I don't see why you'd want to wrap this functionality into
NumPy, which has a very well-defined scope and an efficient implentation.
It would be a shame to bloat it with something which is discretely 
different.

I have modified kjbuckets so that it compiles and works with Python 2.x. 
You can pick it up at 

ftp://xray.imsb.au.dk 
/pub/birdwash/packages/Python2.1/SRPMS/python-kjbuckets-2.2-7.src.rpm

Just do "rpm --rebuild" on it.

I sent the patch to the original author, but it appears he is no longer 
maintaining it. Never mind, it works great.

/Morten

-- 
Morten Kjeldgaard   <mo...@im...>             | Phone : +45 89 42 50 26
Institute of Molecular and Structural Biology    | Fax   : +45 86 12 31 78
Aarhus University                                | Home  : +45 86 18 81 80
Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark | http://imsb.au.dk/~mok

[Numpy-discussion] qs on NumPy

[Ralf J. <jue...@in...>]

Hi,

I did not find a way in Python to check whether a Numeric array=20
instance is a shared array or not. Could you confirm: there is no way.

Is there work underway to make Numeric arrays subclassable?

Regards,
Ralf

--=20
--------------------------------------------------------------------------
Ralf J=FCngling
Institut f=FCr Informatik - Lehrstuhl f=FCr Mustererkennung &
Bildverarbeitung
Georges-K=F6hler-Allee              =20
Geb=E4ude 52                                        Tel:
+49-(0)761-203-8215
79110 Freiburg                                    Fax:
+49-(0)761-203-8262
--------------------------------------------------------------------------