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

[Numpy-discussion] re: gcc 3.0 vs. 2.95.2

[Peter S. <so...@cs...>]

Hello,

I just browsed over the archives for Numpy-discussion and saw this, and
decided to sign up.

I work on the ATLAS-project http://math-atlas.sourceforge.net/ and we have
had similar problems with gcc3.0 Gcc 3.0 has a completely new backend
which produces much slower floating point code on i386 machines. It is
most visible on the Athlon, but it also also shows on on P4 and PIII
machines. We havn't yet figured out if there are some optimizations that
can make this go away, but if you need performance stick with the old 2.95
release for now.

By the way, if you would like to use Atlas in NumPy (I don't know if you
do it already) I might be of some help. There is c-interfaces to the BLAS
bundled with ATLAS, supporting both row-major and column-major storage.

Cheers,

Peter.




FROM: Rob
DATE: 09/04/2001 18:02:05
SUBJECT:  [Numpy-discussion] Python and Numpy compiled on Athlon
optimized gcc3.01

Just for kicks last night I installed gcc3.01 which claims to have Athlon
optimization, ie. -march=athlon.  I recompiled Python and Numpy, and then
ran a big simulation.  The new compiler ran 200 seconds slower than the
old gcc2.95 with plain -march=pentium.  I need to go to the gcc website
and see just what optimization they are claiming.  Maybe I should have
also used -02.   Rob.


-- 
The Numeric Python EM Project

http://www.members.home.net/europax

[Numpy-discussion] Re: PEP proposal for round(x,n) enhancement

[Christopher S. <cs...@bl...>]

To Chris and others interested,

Would you mind giving me an opinion here?  I think you made the best
argument for not using the name "round" since floating n is already
accepted by round and changing how n is interpreted would break anyone's
code who passed in n with a non-zero decimal portion.  Sigfig or chop is
an alternative but I really don't like the name "chop" since it's not
descriptive of the rounding that takes place.  Sigfig is ok, but I am
proposing a round function (below) that offers more than just sigfigs. 
So...how about "round2" which has precedence in the atan2() function.  

The two sorts of roundings that can be done with round2() are 1) rounding
to a specified number of significant figures or 2) rounding to the nearest
"x".  The latter is useful if you are making a histogram, for example,
where experimental data values may all be distinct but when the deviation
of values is considered it makes sense to round the observations to a
specified uncertainty, e.g. if two values differ by less than sigma then
they could be considered to be part of the same "bin".

The script is below.

Thanks for any input,
/c

####
from math import floor,log10
def round2(x,n=0,sigs4n=1):
	'''Return x rounded to the specified number of significant digits, n, as
	counted from the first non-zero digit. 
	
	If n=0 (the default value for round2) then the magnitude of the
	number will be returned (e.g. round2(12) returns 10.0).  
	
	If n<0 then x will be rounded to the nearest multiple of n which, by 
	default, will be rounded to 1 digit (e.g. round2(1.23,-.28) will round 
	1.23 to the nearest multiple of 0.3.

	Regardless of n, if x=0, 0 will be returned.'''
	
	if x==0:
		return x
	if n<0:
		n=round2(-n,sigs4n)
		return n*int(x/n+.5)
	if n==0:
		return 10.**(int(floor(log10(abs(x)))))
	return round(x,int(n)-1-int(floor(log10(abs(x)))))
####

[Numpy-discussion] A proposal for a round(x,n) enhancement

[Christopher S. <cs...@bl...>]

Hello,

I would like to see an addition to the round(x,n) function syntax that
would allow 
one to specify that x should be rounded to the nth significant digit as
opposed to 
the nth digit to the left or right of the 1's digit.  I am testing the
waters right 
now on python-list and have not yet submitted a PEP.  

Some there have suggested that it be called a different function.  Someone
else has 
suggested that perhaps it could be added into SciPy or Numeric as a
function there.

I prefer the name round because it describes what you are doing.  Someone
suggested 
that MATLAB has a function called chop that does what I am proposing and at

http://www.math.colostate.edu/~tavener/M561/lab5/lab5.pdf

the document says that the "MATLAB function chop(x,n) rounds (not chops!)
the number 
x to n significant digits."  If this new function was called "chop" then
any previous 
MATLAB users would know what to expect.  (But why call it chop if you are
actually 
rounding?)  

What I think would be nice is to modify round so it can round to a given 
number of sig. figs.  Here is a def called Round that simulates what I am
proposing:


from math import floor,log10
def Round(x,n=0):
	if n%1:
		d=int(10*n)
		return round(x,d-1-int(floor(log10(abs(x)))))
	else:
		return round(x,n)
		
print Round(1.23456,2)   #returns 1.23
print Round(1.23456,0.2) #returns 1.2

The way that I have enhanced round's syntax is to have it check to see if
there is a 
non-zero decimal part to n.  If there is, n is multiplied by 10 and the
resulting 
value is used to compute which digit to round x to.  n=0.1 will round to
the first 
significant digit while n=0.4 and n=1.1 will round to the 4th and 11th,
respectively. 

I don't believe you will run into any numerical issues since even though
something 
like .3 may be represented internally as 0.29999999999999999, multiplying
it by 10 
gets you back to 3 and this value is what is used in the call to round()

I am open to comments about implementation and function name.

/c

[Numpy-discussion] Precision

[Herbert L. R. <he...@do...>]

I have been wanting use Float128 numbers on an Alpha system running =
Linux and Python 2.0.
Float128 does not seem to be available.  At least Float128 is undefined. =


Is the Alpha capable of support Float128 numbers?
If it is, what am I missing to do be able to use it?

Thanks,
Herb

[Numpy-discussion] Dynamic loading and shared libraries article

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

My column this month has a really great article by David Beazley and two
colleagues about how dynamic loading and shared libraries actually work
and some things you can do with it. It is Computing in Science and
Engineering, Sept/Oct 2001, Scientific Programming Department. I found
the article a really big help in understanding this stuff.  The
magazine's web site is http://computer.org/cise.
 
Paul
 

Re: [Numpy-discussion] Problem with import ...

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

> FORTRAN code that I had written.  Everything worked well.  However,
> after I compiled python2.1.1 and Numeric-20.1.0 importing the blas and
> lapack modules no longer provides access to their routines.  Moreover,

Were you relying on symbols from one dynamic module being available to
other dynamic modules? That was never guaranteed in Python, whether or
not it works depends on the platform but also on the Python
interpreter version. I am not aware of any relevant changes in Python
2.1, but then none of my code relies on this.

The only safe way to call C/Fortran code in one dynamic module from
another dynamic module is passing the addresses in CObject objects.

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] unwrap_function

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

Karshi Hasanov wrote:

>  Does NumPy provide "unwrap" function  like in MatLab?

For those who are wondering, this is unwrap in MATLAB:

 UNWRAP Unwrap phase angle.
    UNWRAP(P) unwraps radian phases P by changing absolute
    jumps greater than pi to their 2*pi complement. It unwraps
    along the first non-singleton dimension of P. P can be a
    scalar, vector, matrix, or N-D array.
 
    UNWRAP(P,TOL) uses a jump tolerance of TOL rather
    than the default TOL = pi.
 
    UNWRAP(P,[],DIM) unwraps along dimension DIM using the
    default tolerance. UNWRAP(P,TOL,DIM) uses a jump tolerance
    of TOL.
 
    See also ANGLE, ABS.


And I think the answer is no, but It would be nice... 

-chris


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

[Numpy-discussion] unwrap_function

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

Hi all,
 
 Does NumPy provide "unwrap" function  like in MatLab?

[Numpy-discussion] Problem with import ...

[Todd A. P. Ph.D. <tp...@ac...>]

In migrating from python 1.5.2 and Numeric 13 to python2.1.1 with
Numeric-20.1.0 I have encountered a rather pernicious problem.  I had
previously been using f2py 1.232 to generate modules for the BLAS and
a self-consistent subset of LAPACK.  Importing the thus created blas
and then lapack modules made their FORTRAN routines available to the
FORTRAN code that I had written.  Everything worked well.  However,
after I compiled python2.1.1 and Numeric-20.1.0 importing the blas and
lapack modules no longer provides access to their routines.  Moreover,
I can't even import the lapack module because it requires routines
from the blas module (that it can no longer see).  I get this behavior
on both RedHat 7.1 and 6.1 (e.g. with and without gcc 2.96).  I
verified that python2.2a behaves as 2.1.1 in this regard as well.  I
tried linking generating blas and lapack libraries and linking them
during creation of the shared libraries but that only worked
marginally.  I am still geting unresolved symbol errors.  Has anyone
else seen this problem/difference?  

-Todd

Re: [Numpy-discussion] =?gb2312?B?SXMgdGhlcmUgc29tZSBtZXRob2QgdG8gcmVhbGl6ZSBxciBkZWNvbXBvc3Rpb24=?=

[John J. L. <jj...@po...>]

Try SciPy

http://www.scipy.org/

Lots of wrapped libraries, and other useful stuff.


John

[Numpy-discussion] =?gb2312?B?SXMgdGhlcmUgc29tZSBtZXRob2QgdG8gcmVhbGl6ZSBxciBkZWNvbXBvc3Rpb24=?=

[wqh <wqh...@26...>]

    I find through the doc ,but can not find any.What Numpy support compare with
matlab is too few,can I think we must work hard to make it better.




      IP卡、上网卡两折    史奴比、蜡笔小新全家福                  加入书友会获精美礼品         

Re: [Numpy-discussion] A possible addition to PEP 209

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

> check each of those elements every time something is done on them. In
> principle, if the Python VM knew that A was an array of Floats, it would
> know that A[i,j,k] was a Float, and it would not have to do a check. I

Right, but that would only work for types that are specially treated
by the interpreter. Just knowing that all elements are of the same
type is not enough. In fact, the VM does not do any check, it just
looks up type-specific pointers and calls the relevant functions.

The other question is how much effort the Python developers would be
willing to spend on this, it looks like a very big job to me, in fact
a reimplementation of the interpreter.

> when this is called, the function bound to the "fun" name is passed to
> map, as is the array bound to the name "A". The Array is known to be
> homogeous. map could conceivably compile a version of fun that worked on

Yes, that could be done, provided there is also a means for compiling
type-specific versions of a function.

> I know this is a major programming effort, and will, at best, be years
> away, but I'd like to see Python move in a direction that makes it
> easier to do, and allows small steps to be done at a time. I think
> introducing the concept of a homogenous sequence could help a lot of

I'd say that adding this feature is much less work than doing even the
slightest bit of optimization. I know I am sounding pessimistic here,
but, well, I am...

Konrad.

-- 
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

Re: [Numpy-discussion] A possible addition to PEP 209

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

Konrad Hinsen wrote:

> Such as? Given the overall dynamic nature of Python, I don't see any
> real opportunities outside array-specific code. What optimizations
> could be done knowing *only* that all elements of a sequence are of
> the same type, but without a particular data layout?

I remember Guido's answer to a FAQ a while ago (the current FAQ has a
more terse version) that essentially stated that compiled Python
wouldn't be much faster because of Python's dynamic nature, so that the
expression x = y*z needs to be evaluated to see what type y is, what
type z is, and what it means to multiply them, before the actual
multiplication can take place. All that checking takes a whole lot
longer than the multiplication itself. NumPy, or course, helps this
along, because once it is determined that y and z are both NumPy arrays
of the same shape and type, it can multiply all the elements in a C
loop, without any further type checking.

Where this breaks down, of course, is when you can't express what you
want to do as a set of array functions. Once you learn the tricks these
times are fairly rare (which is why NumPy is useful), but there are
times when you can't use array-math, and need to loop through the
elements of an array and operate on them. Python currently has to type
check each of those elements every time something is done on them. In
principle, if the Python VM knew that A was an array of Floats, it would
know that A[i,j,k] was a Float, and it would not have to do a check. I
think it would be easiest to get optimization in sequence-oriented
operations, such as map() and list comprehensions:

map(fun, A)

when this is called, the function bound to the "fun" name is passed to
map, as is the array bound to the name "A". The Array is known to be
homogeous. map could conceivably compile a version of fun that worked on
the type of the items in A, and then apply that function to all the
elements in A, without type checking, and looping at the speed of C.
This is the kind of optimization I am imagining. Kind of an instant
U-func.

Something similar could be done with list comprehensions.

Of course, most things that can be done with list comprehensions  and
map() can be done with array operators anyway, so the real advantage
would be a smarter compiler that could do that kind of thing inside a
bunch of nested for loops. There is at least one project heading in that
direction:

    * Psyco (Armin Rego) - a run-time specializing virtual machine that
sees
      what sorts of types are input to a function and compiles a type-
or
      value-specific version of that function on-the-fly.  I believe
Armin
      is looking at some JIT code generators in addition to or instead
of
      another virtual machine.

knowing that all the elements of an Array (or any other sequence) are
the same type could help here a lot. Once a particular function was
compiled with a given set of types, it could be called directly on all
the elements of that array (and other arrays) with no type checking.

What it comes down to is that while Python's dynamic nature is
wonderful, and very powerful and flexible, there are many, many, times
that it is not really needed, particularly inside a given small
function. The standard answer about Python optimization is that you just
need to write those few small functions in C. This is only really
practical if they are functions that operate on particular expected
inputs: essentially statically typed input (or at least not totally
general). Even then, it is a substantial effort, even for those with
extensive C experience (unlike me). It would be so much better if a Py2C
or a JIT compiler could optimize those functions for you. 

I know this is a major programming effort, and will, at best, be years
away, but I'd like to see Python move in a direction that makes it
easier to do, and allows small steps to be done at a time. I think
introducing the concept of a homogenous sequence could help a lot of
these efforts. Numeric Arrays would be just a single example. Python
already has strings, and tuples could be marked as homogenous when
created, if they were. So could lists, but since they are mutable, their
homogenaity could change at any time, so it might not be useful.

I may be wrong about all this, I really don't know a whit about writing
compilers or interpreters, or VMs, but I'm throughing around the idea,
to see what I can learn, and see if it makes any sense.

-Chris


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

Re: [Numpy-discussion] A possible addition to PEP 209

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

> benefits when I can use the overloaded operators and ufuncs, etc. Python
> itself still doesn't know that a NumPy array is a homogenous sequence
> (or might be), because it has no concept of such a thing. If the Python
> interpreter knew that it was homogenous, there could be a lot of
> opportunities for performance enhancements.

Such as? Given the overall dynamic nature of Python, I don't see any
real opportunities outside array-specific code. What optimizations
could be done knowing *only* that all elements of a sequence are of
the same type, but without a particular data layout?

Konrad.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------

[Numpy-discussion] =?gb2312?B?Y2FuIEkgdXNlIHN5bWJvbGljIGNvbXB1dGF0aW9uIHdpdGggbnVtcHk/?=

[wqh <wqh...@26...>]

I should use this ,but do not know how,
if it can not,then  which should I use to perform.thanks




      IP卡、上网卡两折    史奴比、蜡笔小新全家福                  加入书友会获精美礼品         

[Numpy-discussion] Numeric 20.2.0 available in CVS or tar form

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

Numeric 20.2.0 is available at Sourceforge or via cvs. The tag for cvs
is r20_2_0.
 
I haven't done the Windows installers yet.
 

[Numpy-discussion] A possible addition to PEP 209

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

Hi all,


I started a recent dission on c.l.p recently
(http://mail.python.org/pipermail/python-list/2001-September/063502.html),
and it brought up an interesting idea.

In general, I'd like to see Python become more array-oriented, which PEP
209 and friends will help with. I want this because it provides a
natural and effecient way of expressing your program, and because there
are large oportunities for performance enhancements. WHile I make a lot
of use of NumPy arrays at the moment, and get substantial performance
benefits when I can use the overloaded operators and ufuncs, etc. Python
itself still doesn't know that a NumPy array is a homogenous sequence
(or might be), because it has no concept of such a thing. If the Python
interpreter knew that it was homogenous, there could be a lot of
opportunities for performance enhancements.

In the above stated thread, I suggested the addition of a "homogenous"
flag to sequences. I havn't gotten an enthusiastic response, but Skip
Montanaro suggested:

"""
One approach might be to propose that the array object be "brought into
the fold" as a builtin object and modifications be made to the virtual
machine so that homogeneity can be assumed when operating on arrays.
"""

PEP 209 does propose that an array object be "brought into the fold" (or
does it? would it be a builtin?, if not, at least being part of the
standard library would be a help ), but it makes no mention of any
modifications to the virtual machine that would allow optimisations
outside of Numeric2 defined functions.

Is this something worth adding?  I understand that it is one thing for
the homogenous sequence (or array) to be acknowledged in the VM, and
quite another for actual optimizations to be written, but we need the
former before we can get the latter.

What do you all think??


-Chris


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

Re: [Numpy-discussion] ToyFDTDpython on Freshmeat yesterday

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

> Rob wrote:
> > Only slowdown was dumping the E fields into a file every few
> > ticks to generate the movie.  I know there must be better ways to dump
> > an array than use indexing-
>
> If you want to dump the binary data, you can use:
>
> file.write(array.tostring)
>
> If you need an ASCI representation, you can use various forms of:
>
> format_string = '%f '* A.shape[1] + '\n'
> for r in range(A.shape[0]):
> 	file.write(format_string%(tuple(A[r,:])))
>
> You could probably use map to speed it up a little as well.
>
> I'd love to see an array-oreinted version of fscanf and fprintf to make
> this faster and easier, but I have yet to get around to writing one.

Check out the IO secion of SciPy.  Numpyio along with a flexible
ASCII_file reader are there.

-Travis

Re: [Numpy-discussion] ToyFDTDpython on Freshmeat yesterday

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

Rob wrote:
> Only slowdown was dumping the E fields into a file every few
> ticks to generate the movie.  I know there must be better ways to dump
> an array than use indexing-  

If you want to dump the binary data, you can use:

file.write(array.tostring)

If you need an ASCI representation, you can use various forms of:

format_string = '%f '* A.shape[1] + '\n' 
for r in range(A.shape[0]):
	file.write(format_string%(tuple(A[r,:])))

You could probably use map to speed it up a little as well.

I'd love to see an array-oreinted version of fscanf and fprintf to make
this faster and easier, but I have yet to get around to writing one.

-Chris



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

[Numpy-discussion] ToyFDTDpython on Freshmeat yesterday

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

From my web statistics it looks like about 100 people downloaded it. 
Should give Numpy a pretty good showing as I got it running almost as
fast as C.  Only slowdown was dumping the E fields into a file every few
ticks to generate the movie.  I know there must be better ways to dump
an array than use indexing-  but I was so excited when I finally got it
to near C speeds that I just let it be.  Rob.
-- 
The Numeric Python EM Project

www.members.home.net/europax

Re: [Numpy-discussion] coercion for array-like objects for ufuncs

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

> Is there a way I can effect this coercion?  I guess I'd prefer not to
> have to inherit from UserArray.

You need to have an __array__ method defined in your class which returns
the NumPy array to operate on.

-Travis

Re: [Numpy-discussion] coercion for array-like objects for ufuncs

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

Hi Chris,

I believe that all you should have to do is define an __array__ function
similar to that in UserArray;

    def __array__(self,t=None):
        if t: return asarray(self.array,t)
        return asarray(self.array)

Replace self.array with whatever you are calling your contained array.

Regards,

-tim

----- Original Message -----
From: "Chris Myers" <my...@tc...>
To: <num...@li...>
Sent: Wednesday, September 05, 2001 11:39 AM
Subject: [Numpy-discussion] coercion for array-like objects for ufuncs


> I have a Python object that contains a NumPy array (among other
> things), and I'd like it to behave like an array in certain
> circumstances.  (For example, I can define __getitem__ on the class so
> that the underlying NumPy array is indexed.)
>
> I'd like to be able to act on such an object with a ufunc, but am
> stymied.  For example, if y is an instance of this array-like class of
> mine, then I get a type error if I try a reduction on it:
>
> >>> Numeric.minimum.reduce(y)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: function not supported for these types, and can't coerce to
supported types
>
>
> Is there a way I can effect this coercion?  I guess I'd prefer not to
> have to inherit from UserArray.
>
> Thanks,
>
> Chris
>
> ==========================================================================
> Chris Myers
> Cornell Theory Center
> --------------------------------------------------------------------------
> 636 Rhodes Hall              email: my...@tc...
> Cornell University           phone: (607) 255-5894 / fax: (607) 254-8888
> Ithaca, NY 14853             http://www.tc.cornell.edu/~myers
> ==========================================================================
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] coercion for array-like objects for ufuncs

[Chris M. <my...@tc...>]

I have a Python object that contains a NumPy array (among other
things), and I'd like it to behave like an array in certain
circumstances.  (For example, I can define __getitem__ on the class so
that the underlying NumPy array is indexed.)

I'd like to be able to act on such an object with a ufunc, but am
stymied.  For example, if y is an instance of this array-like class of
mine, then I get a type error if I try a reduction on it:

>>> Numeric.minimum.reduce(y)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: function not supported for these types, and can't coerce to supported types


Is there a way I can effect this coercion?  I guess I'd prefer not to
have to inherit from UserArray.

Thanks,

Chris

==========================================================================
Chris Myers 
Cornell Theory Center
--------------------------------------------------------------------------
636 Rhodes Hall              email: my...@tc...
Cornell University           phone: (607) 255-5894 / fax: (607) 254-8888
Ithaca, NY 14853             http://www.tc.cornell.edu/~myers
==========================================================================

[Numpy-discussion] Python and Numpy compiled on Athlon optimized gcc3.01

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

Just for kicks last night I installed gcc3.01 which claims to have
Athlon optimization, ie. -march=athlon.  I recompiled Python and Numpy,
and then ran a big simulation.  The new compiler ran 200 seconds slower
than the old gcc2.95 with plain -march=pentium.  I need to go to the gcc
website and see just what optimization they are claiming.  Maybe I
should have also used -02.      Rob.


-- 
The Numeric Python EM Project

www.members.home.net/europax

Re: [Numpy-discussion] another seemingly unNumpyizeable routine

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

I figured this out.  I step JEdge instead of IEdge.  Another big speed
boost.  Rob.

Rob wrote:
> 
> I hate to bother you guys, but this is how I learn.  I have had some
> success using the take() and add.reduce() routines all by myself.
> However this one seems intractable:
> 
> for IEdge in range(0,a.HybrdBoundEdgeNum):
>     for JEdge in range(0,a.HybrdBoundEdgeNum):
>         AVec[IEdge+a.TotInnerEdgeNum] +=
> a.Cdd[IEdge,JEdge]*XVec[JEdge+a.TotInnerEdgeNum]
> 
> ## below is my attempt at this, but it doesn't
> work
> ## h=a.TotInnerEdgeNum
> ## for IEdge in range(0,a.HybrdBoundEdgeNum):
> ##     AVec[IEdge+h] = add.reduce(a.Cdd[IEdge,0:a.HybrdBoundEdgeNum] *
> XVec[h:(h+a.HybrdBoundEdgeNum)])
> 
> I think the problem lies in that add.reduce is using the slice
> 0:a.HybridBoundEdgeNum for Cdd, but then has to contend with XVec slice
> which is offset by h.  Is there any elegant way to deal with this.  This
> routine is part of a sparse matrix multiply routine.  If I could find
> SparsePy, maybe I could eliminate it altogether.
> 
> Thanks,  Rob.
> 
> --
> The Numeric Python EM Project
> 
> www.members.home.net/europax
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
The Numeric Python EM Project

www.members.home.net/europax