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

Re: [Numpy-discussion] sign of modulo

[Eric N. <no...@ph...>]

> Numpy delegates to the C platform's / and % operators, Python does it
> "right".
> 
> Maybe this should go on the FAQ.

Wouldn't it be preferable to change Numpy so it is also "right"?

Re: [Numpy-discussion] sign of modulo

[Warren F. <fo...@SL...>]

On Fri, 12 Oct 2001, Eric Nodwell wrote:
> The Numpy version of modulo uses a different sign convention for
> negative arguments than does Python itself:
...
> Is there a reason for this (hard to imagine), or is this a bug?

Numpy delegates to the C platform's / and % operators, Python does it
"right".

Maybe this should go on the FAQ.

Waren Focke

[Numpy-discussion] sign of modulo

[Eric N. <no...@ph...>]

The Numpy version of modulo uses a different sign convention for
negative arguments than does Python itself:

>>> -5 % 3
1
>>> array((-5,-5)) % 3
array([-2, -2])

(Numpy version 20.2.0, Python version 1.5.2 and version 2.2a4.)

Is there a reason for this (hard to imagine), or is this a bug?

Eric

RE: [Numpy-discussion] drawing with NumPy and PythonCard - SciPy test

[Kevin A. <al...@se...>]

A suggestion was made that I should check out SciPy. I downloaded and
verified that the plt module works fine from within a PythonCard app using
the built-in PythonCard shell. My test was the plt tutorial at
http://www.scipy.org/site_content/tutorials/plot_tutorial

I've emailed some of the SciPy developers, but there seems to be some mail
gateway issues (the mail bounced) on their server right now, so I haven't
heard back from anyone yet.

Given that plt works with PythonCard today, people might be interested in
being able to create dynamic buttons, fields, and methods from the
interactive prompt using SciPy with PythonCard. The follwoing message shows
dynamic method binding.

http://aspn.activestate.com/ASPN/Mail/Message/770015

Adding other widgets such as a field is just as easy as adding a button, it
is the same syntax as used in the resource files, so the following is valid:

>>> comp['field2'] = {'type':'TextField', 'name':'field2', 'position':(0,
30), 'size':(150, -1), 'text':'this is field2'}

For people that want to mostly do interactive sessions, but still be able to
use buttons and fields to speed up data entry... this will probably be
useful in the context of something like SciPy. Let me know if there are
other questions or suggestions.

ka

> -----Original Message-----
> From: num...@li...
> [mailto:num...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, October 08, 2001 10:40 AM
> To: num...@li...
> Subject: [Numpy-discussion] drawing with NumPy and PythonCard
>
>
> Hi,
> I'm the coordinator for the PythonCard project, which is at:
> http://pythoncard.sourceforge.net/
>
> PythonCard provides a GUI framework for building Python applications. The
> project is relatively new, but there are a large number of sample
> applications, including a number of drawing and visualization samples.
> PythonCard already supports loading and drawing of common formats
> like XBM,
> GIF, JPEG, PNG, etc. from disk files.
>
> Last month I started a BitmapCanvas for the framework to simplify
> interactive drawing. Rather than duplicate all of the functionality of the
> Python Imaging Library (PIL) or the various plotting packages already
> available, I want to make it easy to display results created with other
> drawing packages and numPy in PythonCard. To that end, the Bitmap and
> BitmapCanvas class already support PIL. You can convert a PIL RGB image
> to/from a PythonCard bitmap and you can draw a PIL RGB image in a
> BitmapCanvas at a given x, y location. If you're already converting from
> numPy to PIL, you should be able to show your results in
> PythonCard today. I
> will be making a related post about this on the image-sig.
>
> Anyway, what I would like to do is provide similar methods to make it easy
> to convert numPy arrays to images or a bitmap to numPy without
> having to go
> to PIL first. I don't currently use numPy since I don't do any scientific
> computing (and my math skills are pretty pathetic) and most of my programs
> are text or database-oriented, so I'm relying on others to spec out the
> features they need or want. Eventually, I would like to add some visual
> effects to PythonCard such as wipes and fades which would be a perfect use
> of arrays. I want to make sure that PythonCard provides a good
> GUI framework
> for the scientific community. I would appreciate any suggestions, pointers
> to related resources, etc.
>
> PythonCard currently sits on top of wxPython, so if you are
> already working
> with numPy and wxPython I would be very interested to hear about
> it. If you
> would like to get more actively involved, please join the
> PythonCard mailing
> list, which is probably a better place for longer-term
> discussions than the
> numPy list.
> http://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
> Thanks,
>
> ka
> ---
> Kevin Altis
> al...@se...
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

[Numpy-discussion] NumPy compatible GTK-based framework for color images

[Aureli S. F. <Aur...@ip...>]

Hi folks,

A framework for manipulation of images with explicit support for NumPy
arrays has been implemented:

>
>hello,
>i would like to share a programming effort with you concerning the
>display and manipulation of color images using GTK.
>my idea is to have a programming tool which gives easy access to the
>image memory space (using C matrix notation) while allowing the user
>confortable interactive display features like pan/zoom/selection.
>you may have a look at it under:
>
>http://vision.fhg.de/~daniel/pixelpark
>
>greetings, daniel.
>
>Daniel Kottow
>dan...@ip...
>Security and Testing Technology
>http://vision.fhg.de/~daniel
>Production Technology Centre                     Pascalstr. 8 - 9
>Fraunhofer-Institut IPK Berlin                   D - 10587 Berlin


Best regards,
Aureli



#################################
Aureli Soria Frisch
Fraunhofer IPK
Dept. Pattern Recognition

post: Pascalstr. 8-9, 10587 Berlin, Germany
e-mail:au...@ip...
fon: +49 30 39006-150
fax: +49 30 3917517
web: http://vision.fhg.de/~aureli/web-aureli_en.html
#################################

Re: [Numpy-discussion] Warning: be carefull with the use of Fortran Lapack/Blas libraries

[Gerard V. <gve...@la...>]

On Tuesday 09 October 2001 23:14, Jeff Whitaker wrote:
> I have been able to reproduce this error either with the lapack_lite
> included with numeric, or with the lapack3.0 libs on my system.
>
> Gerard:  are you sure the libs you are linking on your system are not
> lapack 2.0?  If not, could you send me some code that triggers the error?
>
>
> -Jeff
After discussion with Jeff, I installed the latest lapack-3.0 (bugfix 2)
and the problem went away. (I suppose I had lapack-3.0-bugfix 1 installed).

Gerard

[Numpy-discussion] slightly OT: Animabob lives with Cygwin!

[Rob <eu...@ho...>]

I'm proud to have made my first GNU-tools port and my first Cygwin port
Animabob-Cygwin-1.0.  Its the visualization package that mates to all of
my Numpy FDTD code.  Get it on my website.  Interestly on my laptop with
Win2K it runs almost as fast as the native FreeBSD code.  Yet on my
machine at work its very slow- I think it has to do with color depth and
screen resolutions.  I'll find out today.

I pretty much gave up on all the other visualization packages for
Windows as they were either giant elephants or couldn't render 3d movies
of array dumps.  OpenDX would have been nice but it dumps core on every
platform I've tried it on.  I'm told this is fixed in CVS.

Rob.
-- 
The Numeric Python EM Project

www.members.home.net/europax

RE: [Numpy-discussion] Warning: be carefull with the use of Fortran Lapack/Blas libraries

[Jeff W. <js...@cd...>]

I have been able to reproduce this error either with the lapack_lite
included with numeric, or with the lapack3.0 libs on my system.

Gerard:  are you sure the libs you are linking on your system are not
lapack 2.0?  If not, could you send me some code that triggers the error?


-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : js...@cd...
325 Broadway                Web    : www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80303-3328 Office : Skaggs Research Cntr 1D-124

Re: [Numpy-discussion] cephes_libs

[Gerard V. <gve...@la...>]

Try SciPy from www.scipy.org

It contains a cephes module and you'll get a lot of other usefull
stuff too

Gerard

On Tuesday 09 October 2001 15:30, Mark Esplin wrote:
> When I installed the cephes libs, I had to comment out three lines in the
> file cephes/protos.h (by putting "//" at the front of each line) to get it
> to compile.  They are line numbers 67-69
>
> //extern int signbit ( double x );
> //extern int isnan ( double x );
> //extern int isfinite ( double x );
>
> It has seemed to run O.K, I assume those varibles are defined somewhere
> else. I am running on SuSE Linux 7.1, Python 2.0, Numeric-19.0.0
>
> On Monday 08 October 2001 04:31 pm, Karshi Hasanov wrote:
> > Hi all,
> >   I've tried to install cephes libs from Travis Oliphan's website, but
> > wasn't able to do it. Is there anybody  knows how to install these libs.
> > I don't know C much,  so didn't understand the instruction for
> > installation. Thanks
_______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] cephes_libs

[Mark E. <mar...@ya...>]

	When I installed the cephes libs, I had to comment out three lines in the 
file cephes/protos.h (by putting "//" at the front of each line) to get it to 
compile.  They are line numbers 67-69

//extern int signbit ( double x );
//extern int isnan ( double x );
//extern int isfinite ( double x );

It has seemed to run O.K, I assume those varibles are defined somewhere else.
I am running on SuSE Linux 7.1, Python 2.0, Numeric-19.0.0

On Monday 08 October 2001 04:31 pm, Karshi Hasanov wrote:
> Hi all,
>   I've tried to install cephes libs from Travis Oliphan's website, but
> wasn't able to do it. Is there anybody  knows how to install these libs.
> I don't know C much,  so didn't understand the instruction for
> installation. Thanks

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: [Numpy-discussion] Warning: be carefull with the use of Fortran Lapack/Blas libraries

[Paul F. D. <pa...@pf...>]

No good deed goes unpunished. The contributor who put in these changes
wanted to improve Numeric, and I accepted the changes because they
seemed to work. I regret that I didn't investigate this in detail but
the truth is I have to depend on strangers. I have no idea what to do
about it.

-----Original Message-----
From: num...@li...
[mailto:num...@li...] On Behalf Of
Gerard Vermeulen
Sent: Monday, October 08, 2001 9:59 AM
To: num...@li...
Subject: [Numpy-discussion] Warning: be carefull with the use of Fortran
Lapack/Blas libraries


When I build Numeric, I allways link the lapack_lite module to the
Fortran Lapack and Blas libraries on my system. This time
(Numeric-20.2.1), when calling the function eigenvalues(), I got a
message saying that parameter 13 of dgeev had a wrong value.

The reason is that the LinearAlgebra.py module assumes that you have a
very recent version of dgeev, that you can use to calculate the
workspace requirements for the real call.

On http://www.netlib.org/lapack/release_notes.html you'll find a table
"The 
following bug fixes have NOT yet been incorporated in a release/update
of LAPACK."

I quote "LAPACK/SRC/dgeev.f -- Corrected error with LQUERY and setting
of WORK(1)".

LinearAlgebra.py assumes that this bug has been corrected.

So, if you want to use LinearAlgebra.py with Fortran Lapack/Blas, you'd
better apply all those patches listed on 
http://www.netlib.org/lapack/release_notes.html

Of course, it is not a bug in LinearAlgebra.py, but I don't know if it
is wise to program LinearAlgebra.py in such a way that you run into this
problem on probably more than 90 % of the Lapack installations. (getting
the latest lapack.tgz is not sufficient)
 
Gerard



_______________________________________________
Numpy-discussion mailing list Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] cephes_libs

[Karshi H. <kar...@ut...>]

Hi all,
  I've tried to install cephes libs from Travis Oliphan's website, but wasn't 
able to do it. Is there anybody  knows how to install these libs.
I don't know C much,  so didn't understand the instruction for installation.
Thanks

[Numpy-discussion] drawing with NumPy and PythonCard

[Kevin A. <al...@se...>]

Hi,
I'm the coordinator for the PythonCard project, which is at:
http://pythoncard.sourceforge.net/

PythonCard provides a GUI framework for building Python applications. The
project is relatively new, but there are a large number of sample
applications, including a number of drawing and visualization samples.
PythonCard already supports loading and drawing of common formats like XBM,
GIF, JPEG, PNG, etc. from disk files.

Last month I started a BitmapCanvas for the framework to simplify
interactive drawing. Rather than duplicate all of the functionality of the
Python Imaging Library (PIL) or the various plotting packages already
available, I want to make it easy to display results created with other
drawing packages and numPy in PythonCard. To that end, the Bitmap and
BitmapCanvas class already support PIL. You can convert a PIL RGB image
to/from a PythonCard bitmap and you can draw a PIL RGB image in a
BitmapCanvas at a given x, y location. If you're already converting from
numPy to PIL, you should be able to show your results in PythonCard today. I
will be making a related post about this on the image-sig.

Anyway, what I would like to do is provide similar methods to make it easy
to convert numPy arrays to images or a bitmap to numPy without having to go
to PIL first. I don't currently use numPy since I don't do any scientific
computing (and my math skills are pretty pathetic) and most of my programs
are text or database-oriented, so I'm relying on others to spec out the
features they need or want. Eventually, I would like to add some visual
effects to PythonCard such as wipes and fades which would be a perfect use
of arrays. I want to make sure that PythonCard provides a good GUI framework
for the scientific community. I would appreciate any suggestions, pointers
to related resources, etc.

PythonCard currently sits on top of wxPython, so if you are already working
with numPy and wxPython I would be very interested to hear about it. If you
would like to get more actively involved, please join the PythonCard mailing
list, which is probably a better place for longer-term discussions than the
numPy list.
http://lists.sourceforge.net/lists/listinfo/pythoncard-users

Thanks,

ka
---
Kevin Altis
al...@se...

[Numpy-discussion] Warning: be carefull with the use of Fortran Lapack/Blas libraries

[Gerard V. <gve...@la...>]

When I build Numeric, I allways link the lapack_lite module to the Fortran
Lapack and Blas libraries on my system.
This time (Numeric-20.2.1), when calling the function eigenvalues(), I got a
message saying that parameter 13 of dgeev had a wrong value.

The reason is that the LinearAlgebra.py module assumes that you have
a very recent version of dgeev, that you can use to calculate the workspace
requirements for the real call.

On http://www.netlib.org/lapack/release_notes.html you'll find a table "The 
following bug fixes have NOT yet been incorporated in a release/update of
LAPACK."

I quote "LAPACK/SRC/dgeev.f -- Corrected error with LQUERY and setting
of WORK(1)".

LinearAlgebra.py assumes that this bug has been corrected.

So, if you want to use LinearAlgebra.py with Fortran Lapack/Blas, you'd
better apply all those patches listed on 
http://www.netlib.org/lapack/release_notes.html

Of course, it is not a bug in LinearAlgebra.py, but I don't know if it is
wise to program LinearAlgebra.py in such a way that you run into this
problem on probably more than 90 % of the Lapack installations.
(getting the latest lapack.tgz is not sufficient)
 
Gerard

[Numpy-discussion] problem with FFT module from Numeric 20.2.0

[Nick E. <nd...@co...>]

I posted on c.l.py about this and was pointed to the NumPy list...

I'm compiling Numeric 20.2.0 from source using gcc 3.0, on a Linux
system running Python 2.1 (also built with gcc 3.0).  Numeric itself
works, but problems occur with FFT:

  >>> import FFT
  Fatal Python error: can't initialize module fftpack
  Abort

Kinda looks to me like fttpack.so wasn't built correctly.  Any
ideas on what is wrong / how to fix?

Cheers,


Nick

-- 
Nick Efford               | nd...@co...
School of Computing       | tel: +44 113 233 6809
Univ. of Leeds, Leeds, UK | WWW: http://www.comp.leeds.ac.uk/nde/

[Numpy-discussion] demo

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

I know this is absolute highest priority:)), but it annoys me every
time... 
Could someone please apply this patch to display the Mandelbrot demo
correctly on wide terminals?

Index: Demo/mandelbrot.py
===================================================================
RCS file: /cvsroot/numpy/Numerical/Demo/mandelbrot.py,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 mandelbrot.py
--- Demo/mandelbrot.py  2000/01/13 21:23:02     1.1.1.1
+++ Demo/mandelbrot.py  2001/10/07 22:27:19
@@ -22,6 +22,7 @@
 
 
 if __name__ == "__main__":
-       print draw(-2.1, 0.7, -1.2, 1.2)
-
+        data = draw(-2.1, 0.7, -1.2, 1.2)
+        for i in range(0, len(data), 81):
+                print data[i:i+81]

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

Re: [Numpy-discussion] Numeric.put bug

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

On Friday 05 October 2001 11:10 am, you wrote:
> Has anyone yet noted this?
>
> The following code works in python1.5.2 (Numeric.__version__ == '11').
> However, in python2.0 (with Numeric.__version__ == '17.1.1') and
> python2.1 (with Numeric.__version__ == '20.0.0'), it doesn't work
> correctly.
> coords[3][3] is mis-assigned. It happens at least on SGI and Sun. I've
> not
> seen anything in the change lists for 20.1 or 20.2 about such a bug.
>

I'm not sure why this worked in Numeric version 11,  but it appears you are 
using the put function incorrectly.  The documentation might need to be fixed 
to emphasize that the index list is interpreted as a one-dimensional index 
into a flattened representation of the array.   The put function does the 
equivalent of the operation:

a.flat[n] = v.flat[n]

In other words, if a is a 2-d array, then the index list does NOT represent 
indices into the rows of the array.  It represents indicies into the 
flattened array.

In your example, the function is working correctly.  It is placing a 12 into 
the 3 position in the array (i.e. row 0 column 3) and placing a 13 into the 
15th position in the array (i.e. row 3 column 3).

Like I said, I'm not sure why this worked in Numeric 11 --- it shouldn't have.

-Travis

[Numpy-discussion] Numeric.put bug

[Lindy L. <li...@sc...>]

Has anyone yet noted this?

The following code works in python1.5.2 (Numeric.__version__ == '11').
However, in python2.0 (with Numeric.__version__ == '17.1.1') and
python2.1 (with Numeric.__version__ == '20.0.0'), it doesn't work
correctly.
coords[3][3] is mis-assigned. It happens at least on SGI and Sun. I've
not
seen anything in the change lists for 20.1 or 20.2 about such a bug.

#
#  bug.py
#
import Numeric

coords = Numeric.resize(Numeric.array(range(17*4)), (17,4))
print "before coords[3]: ", coords[3]

list = [3, 15]

takecoords = Numeric.take(coords, list)
print "takecoords:"
print takecoords

print "coords.iscontiguous: ", coords.iscontiguous()
Numeric.put(coords, list, takecoords)
print "after coords[3]: ", coords[3]



**********************************
William M. Lindstrom, Jr., Ph.D.
Molecular Graphics Laboratory
Department of Molecular Biology, MB-5
The Scripps Research Institute
10550 North Torrey Pines Road
La Jolla, CA 92037-1000
USA
Tel:        (858) 784-2055
Fax:        (858) 784-2860
E-mail:    li...@sc...

[Numpy-discussion] Coding questions for a type change function

[Chris B. <chr...@ho...>]

HI all,

I've written a function (in C) that changes the type of an array, in
place, using the same data block. The reason I need this is because I am
reading in a large block of data from a file that is essentially a set
of records, each one a C struct that has a couple of longs and a char in
it. I read it in as a big array, slice iot to separate the fields, and
then need to change the type. I had been using:

A = fromstring(A.tostring(),Int32)

This works fine, but needs a lot of memory, and it kind of slow
(althought enough faster than the file read that it matters little) The
array can be on order of 10MB however, so the memory issue is a problem.
Anyway, I wrote a function that changes the type of data in an array,
without making any copies of the data. It seems to work but I have a few
questions (code to follow):

1) Is there an easier way to do this? I just notices that PyArray_As1D
takes a type as an input... would it do what I want??

2) Is there a way , at the C levbel to reshape an array. PyArray_Reshape
takes a PyObject, which is kind of awkward, I'd love to pass in a few
integers, or maybe a nd, and a pointer to a dimensions array.

3) What I did do is use PyArray_DescrFromType() to create a new
desciption, and then assign the description pointer of the array to the
new one. This seems to work, but I expect that the old description
memory never gets freed. How do I free it (can you tell I'm a C
newbie?). Note that I have called this function is a loop thousands of
times, and not seen memory use go up, but it's a pretty small structure.

4) If I call PyArray_DescrFromType() with an invalid typcode, I get a
crash. How can I check if the typecode is valid??


The code follows, I'd love any feedback anyone can offer.

-Chris


static PyObject * NumericExtras_changetype(PyObject *self, PyObject
*args) {

    PyArrayObject *Array;

    //int *new_strides;
    //int *new_dimensions;

    PyArray_Descr *NewDescription;

    int TotalBytes;
    int NewElementSize;

    char typecode;

	if (!PyArg_ParseTuple(args, "O!c",
                          &PyArray_Type, &Array,
                          &typecode)) {
      return NULL;
    }
    
    if (!PyArray_ISCONTIGUOUS(Array)){
      PyErr_SetString (PyExc_ValueError,
                       "m must be contiguous");
      return NULL;
    }     

    TotalBytes = PyArray_NBYTES(Array);


    // This will crash if an invalid typecode is passed in.
    NewDescription = PyArray_DescrFromType(typecode);

    NewElementSize = NewDescription->elsize;
    
    if (TotalBytes % NewElementSize > 0){
      PyErr_SetString (PyExc_ValueError,
                       "The input array is the wrong size for the
requested type");
      return NULL;
    }    

    Array->descr = NewDescription;
    // does the old descr need to be freed?? how??

    Array->nd = 1;
    Array->strides[0] = NewElementSize;
    Array->dimensions[0] = TotalBytes / NewElementSize;
    
    return Py_BuildValue("");
}









-- 
Christopher Barker,
Ph.D.                                                           
Chr...@ho...                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

Re: [Numpy-discussion] Changes to improve performance on small matricies

[Chris B. <chr...@ho...>]

Gary Bishop wrote:

> I'm writing to ask if these changes might make a worthy patch to NumPy?
> We have tested them with on Windows2k (both Native and under Cygwin)
> and on Linux. Soon, we'll have a test on Mac OS X.1.

I'd say yes, but we do have to be satisfied with the robustness of the
code, and I have no idea how to go about doing that. 

This brings up a good point. In Numeric.Py, the is the following
comment:

#The following functions are considered builtin, they all might be
#in C some day

I'd love to see that happen. As evidenced by this poster's example,
Numeric could be made a lot faster by optimizing a number of build-in
functions. What would it take to get a "Numeric Optimization project"
going??

A few ideas:

unit tests: If we had unit tests designed for all the built-in
functions, we would have a good way to know if a newly coded C version
is working right.

How-To_Docs: I have tried to write some Numeric extensions myself, and
it is very difficult. Writing one that does something unusual for my
particular application is not so hard with the current docs. In that
case it usually only has to work for one type, I know what shape the
array should be etc. Writing a universal extension to Numeric that would
work on any Numeric Array is a whole lot harder!! I am currently working
on two of these, and the hard parts for me are:

Doing something to all the data in a perhaps discontiguous array of
arbitrary shape. I have soemthing working now, but it's pretty slow.

Having a function work for all types of Arrays: dealing this this kin
dof dynamicism on C is very difficult for me.

The best place to look is clearly the source itself, but I have tried,
and it's pretty darn dense. A How-To would be pretty darn helpful.


I don't know who's going to write these things, but I think you could
enlarge the pool of NumPy developers quite a bit.

If anyone is interested, I have written "fastclip()" which does what
clip() does, but it does it in place, and only works on Floats (see
above) It is very fast for contiguous arrays, and disappointingly slow
on discontiguous arrays (also see above). Utill I get it working on all
types, there isn't much point in submitting it for inclusion in NumPy.

The other two I have written I use for dealing with binary data coming
in from files:

byteswap() does a bytswap in place, whioch is faster an more memory
efficient that the existing bytswapped() method.

changetype() changes the type of the array, using the same data:
changetype(m,typecode) = fromstring(m.tostring(),typecode)

It is a lot faster and memory efficient (the memory was the issue for
me, I'm dealing with up to 10MB arrays), but kind of an obscure need to,
so this may not be a candidate for inclusion in NumPy either. I still
have some questions about my code for that one: I'll post a separate
message about that.

-Chris
-- 
Christopher Barker,
Ph.D.                                                           
Chr...@ho...                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------

[Numpy-discussion] pgcc (Portland Group C compiler) performance improvements for Numeric applications?

[Joe V. A. <van...@at...>]

Has anyone benchmarked their Numeric applications using 'pgcc'?  I'm
interested in improving the performance of my Numeric Python code, and
I'm wondering what speedup I might achieve, just by re-compiling Python,
Numeric, and my extensions with pgcc.  (We currently use gcc 2.95.3)

Also, has anyone used the multiprocessor (OpenMP) or CDK (Cluster
Development Kit) tools from Portland Group?
-- 
Joe VanAndel  	          
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: van...@uc...

[Numpy-discussion] Changes to improve performance on small matricies

[Gary B. <gb...@cs...>]

We are porting some code from Matlab that does many thousands of 
operations on small matrices. We have found that some small changes to 
LinearAlgebra.py, Numeric.py, and multiarraymodule.c make our code run 
approximately twice as fast as with the unmodified Numeric-20.2 code.

Our changes specifically replace LinearAlgebra._castCopyAndTranspose 
with a version we call _fastCopyAndTranspose that does most of the work 
in C instead of calling Numeric.transpose, which calls arange, which is 
quite expensive. We also optimized Numeric.dot to call a new function 
multiarray.matrixproduct which does the axis swap on the fly instead of 
calling swapaxes (which calls arange) and then calling innerproduct 
(which as the very first step copies the transposed matrix to make it 
contiguous).

Formerly our code spent much of its time in arange (which we never 
explicitly call), dot, and _castCopyAndTranspose. The changes described 
above eliminate this overhead.

I'm writing to ask if these changes might make a worthy patch to NumPy? 
We have tested them with on Windows2k (both Native and under Cygwin) 
and on Linux. Soon, we'll have a test on Mac OS X.1.

If anyone is interested, I will figure out how to generate a patch file 
to submit.

Thanks
gb

Re: [Numpy-discussion] ANN: gracePlot.py

[Rob <eu...@ho...>]

Thanks Peauru for the info.  I tried to install the FreeBSD vtk port,
but it won't compile.  It ran for an hour and then crashed.  I did
install it on windows so we'll see how that works today.  I've been
focusing most of my effort to port Animabob to Cygwin.  I am very
impressed with Cygwin so far as its XFree86 was easy to set up with no
XFree86config.  I also found the OpenDX port to Cygwin, so I'll play
with that a little as well.

Rob.

Pearu Peterson wrote:
> 
> On Fri, 28 Sep 2001, Nathaniel Gray wrote:
> 
> > Nope.  Grace is only for 2-d plots AFAIK.  See their website for more info.
> > You might want to check out VTK and OpenDX, both of which have entries in the
> 
> Rob, have you tried Mayavi (http://mayavi.sourceforge.net) that is
> fully 3D capable. And see http://cens.ioc.ee/projects/pyvtk/ that is
> prototype software to create VTK files from Python objects.
> 
> Regards,
>         Pearu
> 
> The following fragment is from Mayavi README.txt:
> 
>                  The MayaVi Data Visualizer
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> MayaVi is a free, easy to use scientific data visualizer.  It is
> written in Python and uses the amazing Visualization Toolkit (VTK) for
> the graphics.  It provides a GUI written using.  MayaVi is free and
> distributed under the GNU GPL.  It is also cross platform and should
> run on any platform where both Python and VTK are available (which is
> almost any *nix, Mac OSX or Windows).
> <snip>

-- 
The Numeric Python EM Project

www.members.home.net/europax

Re: [Numpy-discussion] ANN: gracePlot.py

[Pearu P. <pe...@ce...>]

On Fri, 28 Sep 2001, Nathaniel Gray wrote:

> Nope.  Grace is only for 2-d plots AFAIK.  See their website for more info.  
> You might want to check out VTK and OpenDX, both of which have entries in the 

Rob, have you tried Mayavi (http://mayavi.sourceforge.net) that is
fully 3D capable. And see http://cens.ioc.ee/projects/pyvtk/ that is
prototype software to create VTK files from Python objects.

Regards,
	Pearu

The following fragment is from Mayavi README.txt:

                 The MayaVi Data Visualizer
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

MayaVi is a free, easy to use scientific data visualizer.  It is
written in Python and uses the amazing Visualization Toolkit (VTK) for
the graphics.  It provides a GUI written using.  MayaVi is free and
distributed under the GNU GPL.  It is also cross platform and should
run on any platform where both Python and VTK are available (which is
almost any *nix, Mac OSX or Windows).
<snip>

Re: [Numpy-discussion] ANN: gracePlot.py

[Nathaniel G. <n8...@ca...>]

Nope.  Grace is only for 2-d plots AFAIK.  See their website for more info.  
You might want to check out VTK and OpenDX, both of which have entries in the 
Vaults of Parnassus.  I've never tried either one but both look like 
industrial strength volume visualization packages and both have python 
bindings.

-n8

On Friday 28 September 2001 05:23 pm, Rob wrote:
> Can it do any 3d volume rendering?  I've heard of grace, but know
> nothing about it.  Rob.
>
> Nathaniel Gray wrote:
> >      __________________________________________________________________
> >
> >                      Announcing:  gracePlot.py v0.5
> >
> >              An interactive, user-friendly python interface to the
> >                          Grace plotting package.
> >
> >      __________________________________________________________________
> >



-- 
Nathaniel Gray

California Institute of Technology
Computation and Neural Systems
--