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

Re: [Numpy-discussion] Can you enumerate an array?

[Chris B. <Chr...@no...>]

Arnd,

You've written some nice compact code, but it only works for rank-2 
arrays. Did you see Travis' solution? I think he's put it (or a C 
version, I'm not sure about that) in scipy_base. However, not using flat 
is nice, as in Numeric and numarray is sometimes makes a copy, and 
sometimes doesn't.

-Chris

Travis Oliphant wrote:
> class ndenumerate(enumerate):
>    def __init__(self, arr):
>        self.iter = enumerate(arr.flat)
>        self.ashape = arr.shape
>        self.nd = arr.ndim
>        self.tot = arr.size
>        self.factors = [None]*(self.nd-1)
>        val = self.ashape[-1]
>        for i in range(self.nd-1,0,-1):
>            self.factors[i-1] = val
>            val *= self.ashape[i-1]
> 
>    def __len__(self):
>        return self.tot
> 
>    def next(self):
>        res = self.iter.next()
>        indxs = [None]*self.nd
>        val = res[0]
>        for i in range(self.nd-1):
>            indxs[i] = val / self.factors[i]
>            val = val % self.factors[i]
>        indxs[self.nd-1] = val
>        return tuple(indxs), res[1]

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

Chr...@no...

Re: [Numpy-discussion] Can you enumerarte an array?

[Arnd B. <arn...@we...>]

Hi Chris,

On Mon, 10 Oct 2005, Chris Barker wrote:

> Travis Oliphant wrote:
> > All flavors of Numeric would return
> >
> > 0  a[0]
> > 1  a[1]
> > .
> > .
> > .
> > n-1  a[n-1]
> >
> > where n=a.shape[0]
> >
> > in response to index, item in enumerate(A):
>
> Right, as expected, and as Anrd pointed out, this is useful behaviour.
>
> > In scipy you could also get
> >
> > 0 a.flat[0]
> > 1 a.flat[1]
>
> I do like the new flat!
>
> > To do something like he wants, I think we would have to construct a
> > different iterator then enumerate.
>
> Exactly,. I didn't mean to imply that that's what the built-in enumerate
> should do.
>
> > It wouldn't be that hard using the
> > a.flat iterator (it's just a remapping of the 1-d index).
>
> Cool. then again, consider this a feature request, for a nd_enumerate,
> or whatever you want to call it.
>
> I'm sorry that implimenting something like this myself is way out my depth!

Below is one way to do it. BUT:
- it is the first iterator I ever wrote...
- it is not using yield, which might be better style -
  Oh and indeed it does give nicer code (see example 1).
- it does not use a.flat.

(BTW: I found
  http://heather.cs.ucdavis.edu/~matloff/Python/PyIterGen.pdf
helpful)

Best,

Arnd


1) Short variant
----------------

from Numeric import *

def arr_enumerate(arr):
    for indy in xrange(arr.shape[1]):
        for indx in xrange(arr.shape[0]):
            yield (indy,indx),arr[indy,indx]


if __name__=="__main__":
    x=reshape(arange(25),(5,5))
    print x

    for ind,value in arr_enumerate(x):
        print ind,value



2) Longer variant (just left in for historical reasons ...;-)
-------------------------------------------------------------

from Numeric import *

class arr_enumerate:
    def __init__(self,arr):
        self.Nx,self.Ny=arr.shape    # just assume 2D here
        self.arr=arr
        self.indx=0
        self.indy=0


    def next(self):
        indx=self.indx
        indy=self.indy

        self.indx+=1
        if self.indx==self.Nx:
            self.indx=0
            self.indy+=1

        if self.indy==self.Ny and self.indx==1:
            raise StopIteration

        return (indy,indx),self.arr[indy,indx]

    def __iter__(self):
        return self



if __name__=="__main__":
    x=reshape(arange(25),(5,5))
    print x

    for ind,value in arr_enumerate(x):
        print ind,value
######################################

[Numpy-discussion] question on differential results in windows and debian

[<me...@ar...>]

Hi there-

I have a matrix X, calculate cX=matrixmultiply(transpose(X), X) and finally 
invert it by icX = linear_algebra.inverse(cX)
cX is kind of ill-conditioned, which caused the icX differs a lot between 
windows and debian, after a tiny difference on cX across platforms. Here 
are the results:
In windows:
 >>> x.min()
-0.51187150837988826
 >>> x.max()
0.81517690875232773
 >>> cX = matrixmultiply(transpose(x), x)
 >>> cX.min()
-666.96857541904126
 >>> cX.max()
1073.3945530725441
 >>> import numarray.linear_algebra as la
 >>> icX = la.inverse(cX)
 >>> icX.min()
-3287030277.3580685
 >>> icX.max()
0.0

In debian:
 >>> x.min()
-0.51187150837988826
 >>> x.max()
0.81517690875232773
 >>> cX = matrixmultiply(transpose(x), x)
 >>> cX.min()
-666.96857541898294
 >>> cX.max()
1073.3945530726264
 >>> import numarray.linear_algebra as la
 >>> icX = la.inverse(cX)
 >>> icX.min()
0.0
 >>> icX.max()
84778028554.337051

I don't understand why a multiplication of a matrix and its transpose will 
create a tiny difference across windows and debian, which could be 
disastrous when inverting it.
Please help me. Thanks a lot for your time! BTW, I am using Python2.4 and 
numarray 1.3.2 in both machines.

Best,
Xiangyi

Xiangyi Meng
Department of Agricultural and Resource Economics
Room 303, Giannini Hall #3310
University of California, Berkeley
Berkeley, CA 94720-3310
Tel:  (510) 643-4124
Fax: (510) 643-8911
Email: me...@ar...
           

[Numpy-discussion] Re: Error involving import_libnumarray in packaged program

[Russell E. O. <ro...@ce...>]

In article <434...@st...>,
 Todd Miller <jm...@st...> wrote:

> Russell E. Owen wrote:
> 
> >If I convert my python code to an application (Windows via py2exe or Mac 
> >via bundlebuilder) it fails with the following error:
> >
> >Fatal Python error: Call to API function without first calling 
> >import_libnumarray() in Src/_convmodule.c
>...
> >I can force *all* of numarray into the application, which avoids the 
>...
> Unfortunately,  I think it's just necessary to (a) include all of core 
> numarray and (b) help out automated tools (which choke on circular 
> dependencies) by explicitly listing numarray's core extensions.  

Is there some practical way to include all of core numarray (without 
getting the unused extensions)?

Could "import numarray" itself do the importing of core numarray? Then 
automatic packaging tools would "just work".

-- Russell

Re: [Numpy-discussion] Error involving import_libnumarray in packaged program

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

Russell E. Owen wrote:

>If I convert my python code to an application (Windows via py2exe or Mac 
>via bundlebuilder) it fails with the following error:
>
>Fatal Python error: Call to API function without first calling 
>import_libnumarray() in Src/_convmodule.c
>  
>
This currently (1.3.3) happens when a numarray API function is called 
before the API is successfully initialized.   Although the message was 
intended as an aid to extension writers,  in this case numarray is 
failing to import altogether.     At one point numarray had a fatal 
error for import failures but I removed it at someone's request.  I've 
restored it because I think it's most commonly fatal anyway and removing 
the message just obfuscated the problem.   The non-fatal behavior is now 
in the _import_libnumarray() macro.

>I can force *all* of numarray into the application, which avoids the 
>  
>
This is what you need to do.  It should be possible to factor out (or 
not explicitly list) numarray's Packages,  but core numarray is not 
meant to be distributed in pieces.  The many type-specific extensions 
were only added to work around a compiler problem,  not to lighten 
binary distributions.

>issue. But that is overkill. Is there some simpler way to solve this, 
>  
>
Unfortunately,  I think it's just necessary to (a) include all of core 
numarray and (b) help out automated tools (which choke on circular 
dependencies) by explicitly listing numarray's core extensions.  

Regards,
Todd

[Numpy-discussion] ASP status, docs, and supporting development

[Joe H. <jh...@oo...>]

After SciPy '04, Perry, Janet, and a few others and I put together a
roadmap and framework, called ASP, for people to contribute to all the
parts of SciPy other than the software: docs, packaging, website, etc.
There was much interest expressed, and a few people even signed on the
electronic dotted line to be involved:

http://www.scipy.org/wikis/accessible_scipy/AccessibleSciPy

The roadmap is laid out in this thread, which is linked in the first
paragraph of the page above:

http://www.scipy.org/mailinglists/mailman?fn=scipy-dev/2004-October/002412.html

The first thing we did was to gather all the external projects using
SciPy that we could find, and make an index page.  The community found
them and Fernando Perez did the hard work (more than he bargained for)
of collating everything into the index page:

http://www.scipy.org/wikis/topical_software/TopicalSoftware

That is now a live wiki page, so if your project isn't on there,
please add it!

We were gearing up for effort #2, a web-site overhaul, early this
year, when Travis announced his intention to heal the rift between the
small- and large-array communities.  We held up our push on web
development, which was a few days from kickoff, so that it wouldn't
take volunteers from his more-crucial effort.

We all know the story of last year: Travis worked like crazy, called
for volunteers, got only a few, and finished the job anyway.  Now he's
publishing a book in hopes of supporting some of his work from the
revenues.  He's made it clear that he will not be offended by or
opposed to free docs, and may even contribute to them.  He's also
still Head Nummie and is leading the hard work of testing and bug
swatting.  Of course, we all want him to continue, and most of us
freely admit our getting more than we are giving, and our gratitude to
Travis, Todd, Robert, and the other core developers.

Meanwhile, we have the problem of needing some basic docs that are
free, and there seems to be quite a bit of interest in the community
for doing one or more free docs.  This seems to have more community
energy behind it now than a web overhaul, so let's do it.

The wiki and procedures are all set up to do some docs, and have been
for about a year now.  If you're interested in doing some docs, either
as the lead author of a doc, as a contributor, or as a reviewer,
please sign up on

http://www.scipy.org/wikis/accessible_scipy/AccessibleSciPy

The goal of the signups page is to make it easy for people to find
each other: for lead authors to find people who will help them, for
the community to identify who is taking part in what efforts, for
low-level-of-effort volunteers to become hooked up with bigger
projects, etc.  There should be dozens of names there, not just three!

So:

If you're interested in LEADING A DOC, please add your name to the
page, make a page for your doc on the wiki, and hang it off the main
page, as "Scipy Cookbook" has done (there's a help link at the top of
the page with instructions).  A project can be anything from writing a
collaborative book from scratch, to writing a monograph, to editing
and revising existing docs.  Announce your project on scipy-dev.

If you would like to do a little work but not take the lead on
something, you can contribute to the Cookbook or sign up to be a
reviewer or contributor, either on an existing doc or at large.  Or,
contact a doc lead directly and sign up under that project.

Please read the roadmap for ideas of docs we thought the community
needs.  The roadmap document is meant to be amended.  For example, is
the idea of using the docstrings to make a full-blown reference manual
a good idea?  I think so, since it's a rather self-updating format,
but it will require some substantial work to get them all fleshed out
and up to par.  Discuss plans, changes, and ongoing efforts for docs
on the scipy-dev mailing.

It would be nice to have each project have a home on scipy.org, and
Plone has excellent workflow-management tools.  But, it's ok to home a
project on your own site and just put a link on scipy.org.

Finally, PLEASE everyone buy Travis's book if you can!  Wait for the
price to go up.  Buy copies for everyone in your lab, if you can
afford that.  Buy one for your grandmother.  It looks like it will be
a really nice book, but it's more than that.  This is a way to support
development, which everyone desperately needs but few have the time
(and fewer the skill and experience) to do.  If you're at a company
that benefits from SciPy and that hasn't already contributed resources
to the effort, please consider parting with a larger chunk of change,
either by buying more copies or by hiring Travis or others directly to
do ongoing maintenance and package development.

--jh--

[Numpy-discussion] Problems compiling ufuncs example (2)

[Kosta G. <ko...@sk...>]

Kosta Gaitanis wrote:
Hi again,
I downloaded mingw32 and this seemed to fix the compilator problem. 
However I still can't build the ufunc example !

This time I tried :

       python setup.py build_ext --compiler=mingw32

and get the following output:

    running build_ext
    building 'numarray.foo._foo' extension
    c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Iinclude
    -Iinclude/numarray -Ic
    :\python24\Include
    umarray -IC:\Python24\include -IC:\Python24\PC -c foo/Src/_foo.c -o
    build\temp.w
    in32-2.4\Release\foo\src\_foo.o
    foo/Src/_foo.c:8: warning: ignoring #pragma warning
    foo/Src/_foo.c: In function `init_funcDict':
    foo/Src/_foo.c:26: warning: unused variable `keytuple'
    foo/Src/_foo.c:26: warning: unused variable `cfunc'
    writing build\temp.win32-2.4\Release\foo\src\_foo.def
    c:\mingw\bin\gcc.exe -mno-cygwin -shared -s
    build\temp.win32-2.4\Release\foo\src
    \_foo.o build\temp.win32-2.4\Release\foo\src\_foo.def -LLib
    -LC:\Python24\libs -
    LC:\Python24\PCBuild -lpython24 -lmsvcr71 -o
    build\lib.win32-2.4\numarray\foo\_f
    oo.pyd
    build\temp.win32-2.4\Release\foo\src\_foo.o(.text+0x87):_foo.c:
    undefined refere
    nce to `_imp__PyCObject_Type'
    build\temp.win32-2.4\Release\foo\src\_foo.o(.text+0xa6):_foo.c:
    undefined refere
    nce to `_imp__PyExc_ImportError'
    collect2: ld returned 1 exit status
    error: command 'gcc' failed with exit status 1

If I remove the comments from the line     libraries = ['ttf']    (at 
the end of setup.py) and try again I get this error :

    running build_ext
    building 'numarray.foo._foo' extension
    c:\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Iinclude
    -Iinclude/numarray -Ic
    :\python24\Include
    umarray -IC:\Python24\include -IC:\Python24\PC -c foo/Src/_foo.c -o
    build\temp.w
    in32-2.4\Release\foo\src\_foo.o
    foo/Src/_foo.c:8: warning: ignoring #pragma warning
    foo/Src/_foo.c: In function `init_funcDict':
    foo/Src/_foo.c:26: warning: unused variable `keytuple'
    foo/Src/_foo.c:26: warning: unused variable `cfunc'
    writing build\temp.win32-2.4\Release\foo\src\_foo.def
    c:\mingw\bin\gcc.exe -mno-cygwin -shared -s
    build\temp.win32-2.4\Release\foo\src
    \_foo.o build\temp.win32-2.4\Release\foo\src\_foo.def -LLib
    -LC:\Python24\libs -
    LC:\Python24\PCBuild -lttf -lpython24 -lmsvcr71 -o
    build\lib.win32-2.4\numarray\
    foo\_foo.pyd
    c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe:
    cannot fin
    d -lttf
    collect2: ld returned 1 exit status
    error: command 'gcc' failed with exit status 1

Can someone tell me what I'm doing wrong please.

Thanks
Kosta

> Hi all,
>
> I'm trying to run the UFunc example in the Numarray manual 
> (http://stsdas.stsci.edu/numarray/numarray-1.1.html/node32.html)
> but when I run the command
>
>    python setup.py buil_ext
>
>
> I get the following output :
>
>    running build_ext
>    error: Python was built with version 7.1 of Visual Studio, and
>    extensions need t
>    o be built with the same version of the compiler, but it isn't 
> installed
>
>
> so I installed Visual C++ Toolkit 2003 and then run the same command 
> again and got the following output :
>
>    running build_ext
>    error: the .NET Framework SDK needs to be installed before building
>    extensions f
>    or Python
>
>
> so I installed .NET Framework SDK 1.1 and then tried again.
> I got back the first error...
>
> does anyone have an idea ? What am I doing wrong ?
>
> thanks in advance
> Kosta
>
> I'm using Python24 and NumArray 1.3.3
>
>
> -- setup.py --
> """ This setup demonstrates how to use the numarray code generation
> facilities to define additional ufuncs at the user level.  Universal
> functions apply operators or C-functions elementwise to all of the
> elements of an array or pair of arrays. This setup generates code
> defining three universal functions which are installed as the
> numarray.foo package: Cos, bessel, and bar.
>
> The ufuncs are used like this:
>
> >>> import numarray as na
> >>> import numarray.foo as foo
> >>> a = na.array([1,2,3,4], type='Int32')
> >>> foo.Cos(a)
> array([ 0.54030228, -0.41614684, -0.9899925 , -0.65364361 ], 
> type=Float32)
>
> Note that since a is an Int32 array, Cos(a) first does blockwise
> conversion of a to Float32 before calling the cosine library function.
> """
>
> import distutils, os
> from distutils.core import setup
> from numarray.numarrayext import NumarrayExtension
> from numarray.codegenerator import UfuncModule, make_stub
>
> # ======================================================================
> #
> # Generate the C-code for the numarray.foo._foo extension:
> #
>
> m = UfuncModule("_foo")          
>
> # Inline the code for a couple C functions to be turned into ufuncs.
> # This method lets you define your function here in the setup.py.  An
> # alternate approach would be to link with a libarary or additional C
> # module.
> m.add_code("""
>
> static double c_bessel(double x, double y)
> {
>      double x2=x*x, y2=y*y, diff=x2-y2;
>      return diff*diff/(x2+y2);
> }
>
> static UInt8  c_bar(UInt32 x )
> {
>      return (x >> 24) & 0xFF;
> }
>
> """)
>
> # Method add_ufunc() defines the name of a ufunc, it's corresponding C
> # function which is applied element-wise to all elements of an array,
> # The arity of the ufunc (unary or binary only), and the I/O type
> # signatures which are directly supported by the ufunc.  Binary Ufunc
> # "bessel" is implemented by the inline function "c_bessel" from the
> # add_code() call above.
>
> m.add_ufunc("bessel", "c_bessel", 2, [('Float32', 'Float32'),
>                                      ('Float64', 'Float64')])
>
> # Unary Ufunc "bar" only supports one builtin type signature:
> # UInt32-->UInt8.  Other types are blockwise converted by the ufunc
> # machinery to UInt32 before "c_bar" is called.
>
> m.add_ufunc("bar", "c_bar", 1, [('UInt32','UInt8')])
>
> # Unary Ufunc "cos" is implemented by the C standard library function
> # "cos".  Given a Float32 array, it returns a Float32 array.  Given a
> # Float64 array, it returns a Float64 array.  For other arrays,
> # transparent conversion to one of the supported input types is performed
> # by the ufunc machinery.
>
> m.add_ufunc("cos", "cos", 1, [('Float32', 'Float32'),
>                              ('Float64', 'Float64')])
>
> # The generate() method writes out the complete extension module to the
> # specified C file.
> m.generate("foo/Src/_foo.c")
>
> # ======================================================================
> # Create foo's __init__.py for defining UFuncs corresponding to CFuncs
> # in _foo.  make_stub() emits boiler-plate which makes your extension
> # a package.  The __init__ file imports all the public symbols from
> # C extension _foo making them visible as numarray.foo.
>
> make_stub("foo/Lib/__init__", "_foo")
> # ======================================================================
> #
> # Standard distutils setup for the generated code.
> #
> setup(name = "foo",
>      version = "0.1",
>      maintainer = "Todd Miller",
>      maintainer_email = "jm...@st...",
>      description = "foo universal functions for numarray",
>      url = "http://www.stsci.edu/projects/foo/",
>      packages = ["numarray.foo"],
>      package_dir = { "numarray.foo":"foo/Lib" },
>      ext_modules = [ NumarrayExtension( 'numarray.foo._foo', 
> ['foo/Src/_foo.c'],
>                                         # libraries = ['ttf'],
>                                         # include_dirs = ['include'],
>                                         # library_dirs = ['lib']
>                                         )
>                      ]
>      )
>
>

Re: [Numpy-discussion] Re: NumPies future

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

A Dilluns 10 Octubre 2005 23:39, Travis Oliphant va escriure:
> No need to give up C++ coding either with weave and pyrex (and f2py
> which can wrap C-code as well).

No, pyrex is not ready for C++ yet (at least natively, i.e. without C
wrappers), but it would eventually be, with Greg permission.

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] Re: NumPies future

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

Travis Oliphant <oli...@ee...> writes:

> I actually do think that converting the numarray manual will be easier.=
=20=20

easier than?

> Because it is closer in function to what current scipy is.=20

closer than what?

> No need to give up C++ coding either with weave and pyrex (and f2py=20
> which can wrap C-code as well).

I don't really want to program C++ -- I want a simple environment
that's available on the typical number cruncher... Therefore, having
scipy on every system would be a solution;)

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

Re: [Numpy-discussion] Re: NumPies future

[Chris B. <Chr...@no...>]

Travis Oliphant wrote:

> No need to give up C++ coding either with weave and pyrex

And SWIG and Boost::Python, which appears to have NumPy support...Has 
anyone used that, and can tell me about how well it works?

-Chris


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

[Numpy-discussion] Error involving import_libnumarray in packaged program

[Russell E. O. <ro...@ce...>]

If I convert my python code to an application (Windows via py2exe or Mac 
via bundlebuilder) it fails with the following error:

Fatal Python error: Call to API function without first calling 
import_libnumarray() in Src/_convmodule.c

I can force *all* of numarray into the application, which avoids the 
issue. But that is overkill. Is there some simpler way to solve this, 
e.g. some an import or command in my code that will prevent this from 
happening?

-- Russell

[Numpy-discussion] Re: NumPies future

[Travis O. <oli...@ee...>]

Jochen Küpper wrote:

>All,
>
>following all this up and down I decide to write a short email for two
>reasons:
>
>First of all I want to thank all developers of Numeric, numarray, and
>the yet to fly scipy_core, esp. Perry/Todd and Travis. I hope that
>this apparent joining of forces will really get Numeric Python a big
>step ahead.
>
>On the other hand I have personally stepped down from using Python for
>larger numerical calculation projects, because it was too much of an
>hassle to get sysops convinced to install it, and because overall the
>hassles to follow releases, adopting code and explaining colleagues
>was to big to make up for the ease of coding compared to C++. Yep,
>there we are. I am REALLY looking forward to the day when I can start
>a larger project in Python again. I wish and hope that you guys are
>paving the road for me;) [1]
>
>Using scipy_core I would also be happy to work on public
>documentation, as that is where everybody using scipy_core can easily
>contribute his share. Maybe it would be a nice team effort to get the
>numarray Python-style documentation cut down and updated to a good and
>current reference-manual, pretty much a nicer and cross-linked version
>of the doc-strings, maybe with more of the examples that were
>discussed here before. I am sure that Travis writes a good
>user-manual, and, voila, both would be in the right place!
>  
>

I actually do think that converting the numarray manual will be easier.  
Because it is closer in function to what current scipy is.    Advanced 
indexing has all been explained (the PEP for SciPy explains what is in 
current SciPy a bit better --- especially when it comes to mixing slices 
and integer indexing arrays.

So, I would start from there.

Hopefully in response to Jochen's other question (regarding hassles of 
install) we can get to the point where scipy core is installed by 
default on everybody's system.... :-)

No need to give up C++ coding either with weave and pyrex (and f2py 
which can wrap C-code as well).

-Travis

NumPies future (was: [Numpy-discussion] Re: Purchasing Documentation)

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

All,

following all this up and down I decide to write a short email for two
reasons:

First of all I want to thank all developers of Numeric, numarray, and
the yet to fly scipy_core, esp. Perry/Todd and Travis. I hope that
this apparent joining of forces will really get Numeric Python a big
step ahead.

On the other hand I have personally stepped down from using Python for
larger numerical calculation projects, because it was too much of an
hassle to get sysops convinced to install it, and because overall the
hassles to follow releases, adopting code and explaining colleagues
was to big to make up for the ease of coding compared to C++. Yep,
there we are. I am REALLY looking forward to the day when I can start
a larger project in Python again. I wish and hope that you guys are
paving the road for me;) [1]

Using scipy_core I would also be happy to work on public
documentation, as that is where everybody using scipy_core can easily
contribute his share. Maybe it would be a nice team effort to get the
numarray Python-style documentation cut down and updated to a good and
current reference-manual, pretty much a nicer and cross-linked version
of the doc-strings, maybe with more of the examples that were
discussed here before. I am sure that Travis writes a good
user-manual, and, voila, both would be in the right place!

To all the guys actually doing the work: Thank you very much, nevertheless!

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

Re: [Numpy-discussion] Can you enumerarte an array?

[Chris B. <Chr...@no...>]

Travis Oliphant wrote:
> All flavors of Numeric would return
> 
> 0  a[0]
> 1  a[1]
> .
> .
> .
> n-1  a[n-1]
> 
> where n=a.shape[0]
> 
> in response to index, item in enumerate(A):

Right, as expected, and as Anrd pointed out, this is useful behaviour.

> In scipy you could also get
> 
> 0 a.flat[0]
> 1 a.flat[1]

I do like the new flat!

> To do something like he wants, I think we would have to construct a 
> different iterator then enumerate.

Exactly,. I didn't mean to imply that that's what the built-in enumerate 
should do.

> It wouldn't be that hard using the 
> a.flat iterator (it's just a remapping of the 1-d index).

Cool. then again, consider this a feature request, for a nd_enumerate, 
or whatever you want to call it.

I'm sorry that implimenting something like this myself is way out my depth!

-Chris

Re: [Numpy-discussion] Access to online documeation - was Purchasing Documentation

[Eric F. <ef...@ha...>]

Colin,

The tab completion works on Linux from the standard python prompt and 
from ipython; the "?" syntax is added by ipython 
(http://ipython.scipy.org/).

Eric

> Could someone elaborate on the remark below please?:
> 
> There was a good reason for my asking this question:  I personally find 
> that
> when coding, the most productive and efficient to learn a library is by 
> typing
> 
> import foo
> foo.<TAB>
> 
> and then
> 
> foo.bar?
>  
> 
> Is this with some particular IDE?  Using Windows, I don't get this.

[Numpy-discussion] Problems compiling ufuncs example

[Kosta G. <ko...@sk...>]

Hi all,

I'm trying to run the UFunc example in the Numarray manual 
(http://stsdas.stsci.edu/numarray/numarray-1.1.html/node32.html)
 but when I run the command

    python setup.py buil_ext


I get the following output :

    running build_ext
    error: Python was built with version 7.1 of Visual Studio, and
    extensions need t
    o be built with the same version of the compiler, but it isn't installed


so I installed Visual C++ Toolkit 2003 and then run the same command 
again and got the following output :

    running build_ext
    error: the .NET Framework SDK needs to be installed before building
    extensions f
    or Python


so I installed .NET Framework SDK 1.1 and then tried again.
I got back the first error...

does anyone have an idea ? What am I doing wrong ?

thanks in advance
Kosta

I'm using Python24 and NumArray 1.3.3


-- setup.py --
""" This setup demonstrates how to use the numarray code generation
facilities to define additional ufuncs at the user level.  Universal
functions apply operators or C-functions elementwise to all of the
elements of an array or pair of arrays. This setup generates code
defining three universal functions which are installed as the
numarray.foo package: Cos, bessel, and bar.

The ufuncs are used like this:

 >>> import numarray as na
 >>> import numarray.foo as foo
 >>> a = na.array([1,2,3,4], type='Int32')
 >>> foo.Cos(a)
array([ 0.54030228, -0.41614684, -0.9899925 , -0.65364361 ], type=Float32)

Note that since a is an Int32 array, Cos(a) first does blockwise
conversion of a to Float32 before calling the cosine library function.
"""

import distutils, os
from distutils.core import setup
from numarray.numarrayext import NumarrayExtension
from numarray.codegenerator import UfuncModule, make_stub

# ======================================================================
#
# Generate the C-code for the numarray.foo._foo extension:
#

m = UfuncModule("_foo")           


# Inline the code for a couple C functions to be turned into ufuncs.
# This method lets you define your function here in the setup.py.  An
# alternate approach would be to link with a libarary or additional C
# module.
m.add_code("""

static double c_bessel(double x, double y)
{
      double x2=x*x, y2=y*y, diff=x2-y2;
      return diff*diff/(x2+y2);
}

static UInt8  c_bar(UInt32 x )
{
      return (x >> 24) & 0xFF;
}

""")

# Method add_ufunc() defines the name of a ufunc, it's corresponding C
# function which is applied element-wise to all elements of an array,
# The arity of the ufunc (unary or binary only), and the I/O type
# signatures which are directly supported by the ufunc.  Binary Ufunc
# "bessel" is implemented by the inline function "c_bessel" from the
# add_code() call above.

m.add_ufunc("bessel", "c_bessel", 2, [('Float32', 'Float32'),
                                      ('Float64', 'Float64')])

# Unary Ufunc "bar" only supports one builtin type signature:
# UInt32-->UInt8.  Other types are blockwise converted by the ufunc
# machinery to UInt32 before "c_bar" is called.

m.add_ufunc("bar", "c_bar", 1, [('UInt32','UInt8')])

# Unary Ufunc "cos" is implemented by the C standard library function
# "cos".  Given a Float32 array, it returns a Float32 array.  Given a
# Float64 array, it returns a Float64 array.  For other arrays,
# transparent conversion to one of the supported input types is performed
# by the ufunc machinery.

m.add_ufunc("cos", "cos", 1, [('Float32', 'Float32'),
                              ('Float64', 'Float64')])

# The generate() method writes out the complete extension module to the
# specified C file.
m.generate("foo/Src/_foo.c")

# ======================================================================
# Create foo's __init__.py for defining UFuncs corresponding to CFuncs
# in _foo.  make_stub() emits boiler-plate which makes your extension
# a package.  The __init__ file imports all the public symbols from
# C extension _foo making them visible as numarray.foo.

make_stub("foo/Lib/__init__", "_foo") 

# ======================================================================
#
# Standard distutils setup for the generated code.
#
setup(name = "foo",
      version = "0.1",
      maintainer = "Todd Miller",
      maintainer_email = "jm...@st...",
      description = "foo universal functions for numarray",
      url = "http://www.stsci.edu/projects/foo/",
      packages = ["numarray.foo"],
      package_dir = { "numarray.foo":"foo/Lib" },
      ext_modules = [ NumarrayExtension( 'numarray.foo._foo', 
['foo/Src/_foo.c'],
                                         # libraries = ['ttf'],
                                         # include_dirs = ['include'],
                                         # library_dirs = ['lib']
                                         )
                      ]
      )

Re: [Numpy-discussion] Dcoument strings for ndarray

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

Travis Oliphant wrote:

>
>>> I'm not sure what you are talking about here?  Where are you getting 
>>> this?
>>>
>>>
>>> I don't know of any such attribute.  There is a __class__ 
>>> attribute.  But I don't see a
>>>
>>> __class__ module(name[, doc])   attribute
>>>
>>> -Travis
>>>
>>
>> Please see the sequence below:
>>
>>     >>> import scipy.base.multiarray as M
>>     >>> M.__class__
>>    <type 'module'>
>>     >>>
>>
>> I am surprised that this name points to a module.  It usually is an 
>> attribute of a class instance which
>> points to the class object of that instance.
>
>
> Why is this surprising?   scipy.base.multiarray is a module, therefore 
> it's "class" is type 'module'.  This seems fine to me.   At any rate, 
> Python is assigning the __class__ attribute to the extension module 
> multiarray, so it is what it is.
>
> -Travis
>
Yes, this is the Python practice:
 >>> import timeit
 >>> timeit.__class__
<type 'module'>
 >>> import anydbm
 >>> anydbm.__class__
<type 'module'>
 >>>

Yes, timeit.__class__ points to the internal module creator function:
 >>> import new
 >>> new.module
<type 'module'>
 >>> new.module.__doc__
'module(name[, doc])\n\nCreate a module object.\nThe name must be a 
string; the optional doc argumen
t can have any type.'
 >>> new.module is timeit.__class__
True
 >>>

With a little digging, this is logical, consistent and no longer surprising.

Colin W.

[Numpy-discussion] Access to online documeation - was Purchasing Documentation

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

Matthew Brett wrote:

>Hi,
>
>  
>
>>While I fully respect the opinion of those concerned about Travis' decision, I
>>have to say that I am personally not so worried.  At scipy'05, when Travis
>>announced the book idea, I asked a very simple question: 'are the docstrings
>>complete?'.  His answer was 'yes'.
>>
>>There was a good reason for my asking this question:  I personally find that
>>when coding, the most productive and efficient to learn a library is by typing
>>
>>import foo
>>foo.<TAB>
>>
>>and then
>>
>>foo.bar?
>>    
>>
>
>Just a tiny addition.  I know what you mean, but my experience is of
>someone recently trying to learn numarray / Numeric, and I suspect I
>am not alone in printing out the documentation and reading a moderate
>amount of it before I get started.   Call me old-fashioned (it
>wouldn't be the first time!),
>
>See you,
>
>Matthew
>
>
>  
>
Could someone elaborate on the remark below please?:

There was a good reason for my asking this question:  I personally find that
when coding, the most productive and efficient to learn a library is by typing

import foo
foo.<TAB>

and then

foo.bar?
  

Is this with some particular IDE?  Using Windows, I don't get this.

This sort of help is available with PythonWin but Numeric3 and pythonw 
seem to be mutually incompatible at this stage.

Colin W.

Re: [Numpy-discussion] Can you enumerarte an array?

[Arnd B. <arn...@we...>]

Hi Chris,

On Sun, 9 Oct 2005, Chris Barker wrote:

> Hi all,
>
> A freind of mine that I jsut introduced to NumPy asked me about
> enumerating an array. What he'd like to see is something like:
>
> A = N.ones((3,4))
>
> for indexes, item in enumeate(A):
>      print indexes
>
> result in:
>
> (0,0)
> (0,1)
> (0,2)
> (1,0)
> .
> .
> .
> You get the idea. Can you do this with any of the three NumPys?

Not that I know:

  import Numeric as N
  A = N.ones((3,4))
  for indizes, item in enumerate(A): print indizes,item

gives

  0 [1 1 1 1]
  1 [1 1 1 1]
  2 [1 1 1 1]

(the same applies for numarrary and the new scipy_core)

It might be the best to define your own iterator (e.g. `enumerate_ind`)
because the present behaviour can be useful as well.

> If not
> consider this a feature request for scipy_base.

Best, Arnd

[Numpy-discussion] Can you enumerarte an array?

[Chris B. <Chr...@no...>]

Hi all,

A freind of mine that I jsut introduced to NumPy asked me about 
enumerating an array. What he'd like to see is something like:

A = N.ones((3,4))

for indexes, item in enumeate(A):
     print indexes

result in:

(0,0)
(0,1)
(0,2)
(1,0)
.
.
.
You get the idea. Can you do this with any of the three NumPys? If not 
consider this a feature request for scipy_base.

-Chris

[Numpy-discussion] Question about 64-bit integers being cast to double precision

[Travis O. <oli...@ee...>]

What is the opinion of people here regarding the casting of 64-bit 
integers to double precision.

In scipy (as in Numeric), there is the concept of "Casting safely" to a 
type.  This concept is used when choosing a ufunc, for example. 

My understanding is that a 64-bit integer cannot be cast safely to a 
double-precision floating point number, because precision is lost in the 
conversion.   However, at least a signed 64-bit integer can usually be 
cast safely to a long double precision floating point number.

This is not too big a deal on 32-bit systems where people rarely request 
64-bit integers.

However, on some 64-bit systems (where the C long is 64-bit), Python's 
default integer is 64-bit.  Therefore, simple expressions like sqrt(2) 
which require conversion to floating point will look for the first 
floating point number that it can convert a 64-bit integer to safely.    
This can only be a long double.

The result is that on 64-bit systems, the long double type gets used a 
lot more.   Is this acceptable? expected?   What do those of you on 
64-bit systems think?

-Travis

Re: [Numpy-discussion] Dcoument strings for ndarray

[Greg E. <gre...@ca...>]

Colin J. Williams wrote:

>     >>> import scipy.base.multiarray as M
>     >>> M.__class__
>    <type 'module'>
>     >>>
> 
> I am surprised that this name points to a module.

<type 'module'> is NOT a module, it's the type
(or class) to which all modules belong. This is to
be expected if scipy.base.multiarray is itself a
module.

The reason it says <type 'module'> and not
<class 'module'> is because it's a built-in type/class
rather than one defined in Python. But ever since the
type/class unification, there's very little difference
in meaning between the terms 'type' and 'class'.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
gre...@ca...	   +--------------------------------------+

Re: [Numpy-discussion] Dcoument strings for ndarray

[Travis O. <oli...@ee...>]

>> I'm not sure what you are talking about here?  Where are you getting 
>> this?
>>
>>
>> I don't know of any such attribute.  There is a __class__ attribute.  
>> But I don't see a
>>
>> __class__ module(name[, doc])   attribute
>>
>> -Travis
>>
>
> Please see the sequence below:
>
>     >>> import scipy.base.multiarray as M
>     >>> M.__class__
>    <type 'module'>
>     >>>
>
> I am surprised that this name points to a module.  It usually is an 
> attribute of a class instance which
> points to the class object of that instance.

Why is this surprising?   scipy.base.multiarray is a module, therefore 
it's "class" is type 'module'.  This seems fine to me.   At any rate, 
Python is assigning the __class__ attribute to the extension module 
multiarray, so it is what it is.

-Travis

Re: [SciPy-user] [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

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

Fernando Perez wrote:
> Certainly.  As I said, I do think there is room for 'book-style' (as
> opposed to API reference) books for scipy.  Langtangen's ($$$) and
> Perry's (free) are two such existing offers, and now Travis' comes in as
> well (and I still believe there is room for more).
> 
> My idea was of top-level (module) docstrings which would provide a
> reasonable overview, along with single-function ones providing not only
> API reference but also a few examples.  Since pydoc -w can generate
> permanent HTML for browsing/printing out of any module (and docutils has
> even more sophisticated facilities), I think this provides acceptable
> coverage of the basic library. And it does give anyone who wants
> 'material to read on the bus' (which I often need myself) a reasonable
> solution, I think.
> 
> I just wanted to clarify that a docstring-based set of docs is not
> limited either to interactive usage via ipython, nor to raw API
> information.  It can both be printed for offline use, and can cover
> enough overview and examples to be genuinely useful standalone.  Not a
> substitute for a full book, but not a crippled tool either, I think.

Sounds like the ideal solution to me. Now, I wonder if it is possible to
resolve the legal situation over the existing NumPy documentation? By
which I mean, I wonder if it is possible to just copy suitable parts of
the NumPy docs into the scipy.core docstrings (improving on them if
possible) - with attribution of course. Or is it necessary or safer to
start from scratch, or at least to extensively paraphrase the NumPy docs?

Finally, to whom should we send docstrings? To Travis?

Tim C

Re: [SciPy-user] [SciPy-dev] Re: [Numpy-discussion] Purchasing Documentation

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

Matthew Brett wrote:

>>While I fully respect the opinion of those concerned about Travis' decision, I
>>have to say that I am personally not so worried.  At scipy'05, when Travis
>>announced the book idea, I asked a very simple question: 'are the docstrings
>>complete?'.  His answer was 'yes'.
>>
>>There was a good reason for my asking this question:  I personally find that
>>when coding, the most productive and efficient to learn a library is by typing
>>
>>import foo
>>foo.<TAB>
>>
>>and then
>>
>>foo.bar?
> 
> 
> Just a tiny addition.  I know what you mean, but my experience is of
> someone recently trying to learn numarray / Numeric, and I suspect I
> am not alone in printing out the documentation and reading a moderate
> amount of it before I get started.   Call me old-fashioned (it
> wouldn't be the first time!),

Certainly.  As I said, I do think there is room for 'book-style' (as opposed 
to API reference) books for scipy.  Langtangen's ($$$) and Perry's (free) are 
two such existing offers, and now Travis' comes in as well (and I still 
believe there is room for more).

My idea was of top-level (module) docstrings which would provide a reasonable 
overview, along with single-function ones providing not only API reference but 
also a few examples.  Since pydoc -w can generate permanent HTML for 
browsing/printing out of any module (and docutils has even more sophisticated 
facilities), I think this provides acceptable coverage of the basic library. 
And it does give anyone who wants 'material to read on the bus' (which I often 
need myself) a reasonable solution, I think.

I just wanted to clarify that a docstring-based set of docs is not limited 
either to interactive usage via ipython, nor to raw API information.  It can 
both be printed for offline use, and can cover enough overview and examples to 
be genuinely useful standalone.  Not a substitute for a full book, but not a 
crippled tool either, I think.

Cheers,

f