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

RE: [Numpy-discussion] still no cross product for new array type

[Nadav H. <na...@vi...>]

Usually this is within the scope of higher level packages such as =
ScientificPython.

  Nadav

-----Original Message-----
From:	num...@li... on behalf of Gary =
Ruben
Sent:	Fri 12-Aug-05 14:44
To:	num...@li...
Cc:=09
Subject:	[Numpy-discussion] still no cross product for new array type
Just browsing through the new array PEP to see if there's support for=20
3-vector operations, such as cross product, norm, length functions.=20
Sadly I don't see any. It's something I think is lacking from Numeric=20
and numarray and would like to see implemented. Is it a deliberate=20
choice not to include any? I understand that vectors are sufficiently=20
different animals that you could argue that they shouldn't be supported. =

I use them enough to think that they should be.

Gary Ruben


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle =
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & =
QA
Security * Process Improvement & Measurement * =
http://www.sqe.com/bsce5sf
_______________________________________________
Numpy-discussion mailing list
Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] still no cross product for new array type

[Gary R. <gr...@bi...>]

Just browsing through the new array PEP to see if there's support for 
3-vector operations, such as cross product, norm, length functions. 
Sadly I don't see any. It's something I think is lacking from Numeric 
and numarray and would like to see implemented. Is it a deliberate 
choice not to include any? I understand that vectors are sufficiently 
different animals that you could argue that they shouldn't be supported. 
I use them enough to think that they should be.

Gary Ruben

RE: [Numpy-discussion] new __wrap_array__ magic method

[<Seb...@el...>]

> 
> > __wrap_array__(self, ufunc): # all unary operators like 
> __neg__, __abs__, __invert__
> > __lwrap_array__(self, other, ufunc): # all binary operators 
> called with self on the lhs like __add__, __mul__, __pow__
> > __rwrap_array__(self, other, ufunc): # all binary operators 
> called with self on the rhs like __radd__, __rmul__, __rpow__
> 
> The term "wrap_array" doesn't seem very descriptive of
> what these are for. Wrapping of arrays may come into the
> implementations of them, but it's not the main point.
> The point is to apply a ufunc to the object and get
> an appropriate result.
> 
> Maybe just __ufunc__, __lufunc__, __rufunc__?

Definitely ! I came first with a function that was more similar to __array__ and so __wrap_array__ seemed a plausible name for this function.
Afterward, I changed a bit the role of this function to propose the alternative way and your names are way more adequate (it may be useful to add the unary/binary word in the function like:

__unary_ufunc__
__binary_lufunc__
__binary_rufunc__

as it does not map exactly to __add__, __radd__ and people could mix __ufunc__ and __rufunc__ without understanding the __lufunc__...


> 
> -- 
> Greg Ewing, Computer Science Dept, 
> +--------------------------------------+
> University of Canterbury,	   | A citizen of 
> NewZealandCorp, a	  |
> Christchurch, New Zealand	   | wholly-owned subsidiary of 
> USA Inc.  |
> gre...@ca...	   
+--------------------------------------+
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development 
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * 
> Testing & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 


=======================================================
This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Electrabel may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.

http://www.electrabel.be/homepage/general/disclaimer_EN.asp
=======================================================

Re: [Numpy-discussion] new __wrap_array__ magic method

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

Seb...@el... wrote:

> __wrap_array__(self, ufunc): # all unary operators like __neg__, __abs__, __invert__
> __lwrap_array__(self, other, ufunc): # all binary operators called with self on the lhs like __add__, __mul__, __pow__
> __rwrap_array__(self, other, ufunc): # all binary operators called with self on the rhs like __radd__, __rmul__, __rpow__

The term "wrap_array" doesn't seem very descriptive of
what these are for. Wrapping of arrays may come into the
implementations of them, but it's not the main point.
The point is to apply a ufunc to the object and get
an appropriate result.

Maybe just __ufunc__, __lufunc__, __rufunc__?

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

[Numpy-discussion] Numeric Python EM Project

[Rob <eur...@co...>]

Hi all,

I will be putting this site back up, somewhere, I don't know.  It needs 
to be updated to whatever people think is the best Python numeric type 
package.  I've been out of this for a couple of years.

I'm off to buy a second laptop today.  Something relatively inexpensive 
that will just have Windoze on it.  This pricey Dell is my *nix laptop. 
Currently it has OpenBSD only.

The motivation of all of this is the dismay of "high tech" EE jobs here 
in Hillsboro, OR, and a renewed interest in Astrophysics and all of the 
wonderful philosophic and spiritual questions that naturally come from 
it.  haha.

Sincerely,

Rob N3FT

RE: [Numpy-discussion] new __wrap_array__ magic method

[<Seb...@el...>]

> 
> >Hi,
> >
> >Currently, we have an __array__ magic method that can be 
> used to transform any object that implements it into an array.
> >It think that a more useful magic method would be, for 
> ufuncs, a __wrap_array__ method that would return an array 
> object and a function to use after having applied the ufunc.
> >  
> >
> There is an interest in doing this but it is a bit more 
> complicated for 
> ufuncs with more than one input argument and more than one 
> output argument.
> 
> I have not seen a proposal that really works.    Your __wrap_array__ 
> method sounds interesting though.   I think, however, that the 
> __wrap_array__ method would need to provide some kind of 
> array_interfaceable object to be really useful.
> 
> In the new scipy.base, I've been trying to handle some of 
> this, but it 
> is more complicated than it might at first appear.
> 

If we use the same convention as __add__ and __radd__ & co for binary functions this would make a

__wrap_array__(self, ufunc): # all unary operators like __neg__, __abs__, __invert__
__lwrap_array__(self, other, ufunc): # all binary operators called with self on the lhs like __add__, __mul__, __pow__
__rwrap_array__(self, other, ufunc): # all binary operators called with self on the rhs like __radd__, __rmul__, __rpow__

with first a check on __lwrap_array__ and then __rwrap_array__ for binary functions.
Those functions should then return the result of the operation (and not anymore an array object and a "constructor" function.

My previous example would read:
class TimeSerie:
	def __init__(self, data, times):
		self.data = data      # an array
		self.times = times    # anything, could be any metadata

	def __wrap_array__(self, ufunc):
		return TimeSerie( ufunc(self.data) , self.times)

	def __lwrap_array__(self, other, ufunc):
		return TimeSerie( ufunc(self.data, other) , self.times)

	def __rwrap_array__(self, other, ufunc):
		return TimeSerie( ufunc(other, self.data) , self.times)

propagating this way the operation to the other object in binary operations.

Better attempt ?

Seb


=======================================================
This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Electrabel may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.

http://www.electrabel.be/homepage/general/disclaimer_EN.asp
=======================================================

[Numpy-discussion] Sourceforge pserver CVS access acting strange -> don't get Numeric3 that way.

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

Anyone contemplating trying out the new scipy.base should not try to use 
the pserver CVS service from sourceforge for a while.  It is not 
reflecting the current state of the developer CVS tree. 

I know they recently upgraded developer CVS hardware and perhaps the 
pserver system is still getting information from the old CVS tree rather 
than the new developer tree.

So, if you get errors on building scipy.base after checking it out from 
pserver Sourceforge, wait a day or two.  I suspect that sourceforge will 
fix this annoying  problem soon.

-Travis O.

[Numpy-discussion] Checking out scipy.base (Numeric3)

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

You can check out scipy.base using:

cvs -d:pserver:ano...@cv...:/cvsroot/numpy login
(press Enter when asked for login)

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/numpy co -P 
/Numeric3\


-Travis

/

[Numpy-discussion] scipy.base (Numeric3) ready for alpha use

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

For anybody interested in the development of scipy.base.  The repository 
is in a state that can be tested and played with.

I'm sure there are bugs, but I've removed the ones I've found.  I'd be 
interested in help in tracking down others.

Over the next few weeks, we will be attempting to build scipy using the 
new scipy.base.  This should also help iron out some problems. 

Some of the notable features that came out of the ufunc adapting process are

1) reductions can now take place over a type different than the array 
type.  Thus, if B is a byte array you
    can reduce over a long type to avoid modular arithmetic (overflow).

2) reduceat now takes an axis argument

3) copies are not made of large arrays but a buffering-scheme is used 
for casting and mis-behaved arrays.

4) the size of buffers used and what is meant by "large array" can be 
adjusted on a per function / module / global basis by setting the 
variable UFUNC_BUFSIZE in the local / module / global (builtin) scope

5) how errors in ufuncs are handled can be set and over-ridden on a 
function / module / global basis through the variable UFUNC_ERRMASK

6) you have another option besides ignore, warn, or raise.  You can 
specify a Python function to call when an error occurs through the 
variable UFUNC_ERRFUNC (right now all errors go to this same function 
and a string is based indiciating which error has occurred).

I should explain this idea of using variables to set information for the 
ufuncs.  It comes out of an idea that Guido mentioned while Perry, Paul, 
and I met with him back in March.  When he was informed of numarray's 
stack approach to error handling he questioned that design decision.  He 
wondered if the error handling could not be defined on a per module basis.

With that idea, it was relatively straightforward to implement a 
procedure wherein error behavior for ufuncs is determined by
looking in the local, then global (module level), and finally builtin 
scope for a specific variable.

This look-up is done at the beginning of the ufunc call.  It will 
obviously add some time to code which loops through repeated look up 
calls (how much I'm not sure).  Perhaps there is a way to ameliorate 
this, but until we see some performance issues, I'm not inclined to 
spend too much time on premature optimization.

Comments and especially people with an inkling to try very alpha code 
out (i.e. it could segfault on you) are welcomed.

-Travis O.

Re: [Numpy-discussion] new __wrap_array__ magic method

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

Seb...@el... wrote:

>Hi,
>
>Currently, we have an __array__ magic method that can be used to transform any object that implements it into an array.
>It think that a more useful magic method would be, for ufuncs, a __wrap_array__ method that would return an array object and a function to use after having applied the ufunc.
>  
>
There is an interest in doing this but it is a bit more complicated for 
ufuncs with more than one input argument and more than one output argument.

I have not seen a proposal that really works.    Your __wrap_array__ 
method sounds interesting though.   I think, however, that the 
__wrap_array__ method would need to provide some kind of 
array_interfaceable object to be really useful.

In the new scipy.base, I've been trying to handle some of this, but it 
is more complicated than it might at first appear.

-Travis

[Numpy-discussion] new __wrap_array__ magic method

[<Seb...@el...>]

Hi,

Currently, we have an __array__ magic method that can be used to transform any object that implements it into an array.
It think that a more useful magic method would be, for ufuncs, a __wrap_array__ method that would return an array object and a function to use after having applied the ufunc.

For instance:

class TimeSerie:
	def __init__(self, data, times):
		self.data = data      # an array
		self.times = times    # anything, could be any metadata

	def __wrap_array__(self, ufunc):
		return self.data, lambda data: TimeSerie(data, self.times)

t = TimeSerie( arange(100), range(100) )
cos(t) # returns a TimeSerie object equivalent to TimeSerie( cos(arange(100)), range(100) )

This needs probably a change in the ufunc code that would first check if __wrap_array__ is there and if so, use it to get an array as well as a "constructor" to use for returning an object other than an array.

Benefits:
 - easier to wrap array objects with metadata without rewriting all ufunc (see MaskedArray for problematic).
 - ufunc( list ) -> list and ufunc( tuple ) -> tuple instead of returning always arrays.

Do you see an interest of doing so ? Does it need a lot of internal changes to Numeric/numarray/scipy.core ?

Best,

Sebastien


=======================================================
This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. All messages sent to and from Electrabel may be monitored to ensure compliance with internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. Anyone who communicates with us by email is taken to accept these risks.

http://www.electrabel.be/homepage/general/disclaimer_EN.asp
=======================================================

[Numpy-discussion] re: software skills course

[Greg W. <gvw...@cs...>]

Hi,

I'm working with support from the Python Software Foundation to develop
an open source course on basic software development skills for people
with backgrounds in science and engineering.  I have a beta version of
the course notes ready for review, and would like to pull in people
in sci&eng to look it over and give me feedback.  If you know anyone
who fits this bill (particularly people who might be interested in
following along with a trial run of the course this fall), I'd be
grateful for pointers.

Thanks,
Greg Wilson

[Numpy-discussion] Optimization Question

[Alex S. <ale...@te...>]

Hi,

I made nice function that composts two RGBA image arrays, however I'm 
having issues with it being too slow. Does any body have any suggestions 
on how to optimize this (the subfunction 'maknewpixels' is a separation 
for profiling purposes, and it takes almost as much time as the other 
parts of the function):

def compost(lowerlayer, upperlayer):

    def makenewpixels(ltable, utable, h, w, upperalphatable, 
loweralphatable):
        newpixels = Numeric.zeros((h, w, 4), 'b')
        newpixels[:,:,3] = Numeric.clip(upperalphatable + 
loweralphatable, 0, 255).astype('b')
        newpixels[:,:,0:3] = (utable + ltable).astype('b')
        return newpixels
       
    h = Numeric.size(lowerlayer, 0)
    w = Numeric.size(lowerlayer, 1)
    upperalphatable = upperlayer[:,:,3]
    loweralphatable = lowerlayer[:,:,3]
    #calculate the upper layer's portion of the composted picture
    utable = Numeric.swapaxes(Numeric.swapaxes(upperlayer[:,:,0:3], 0, 
2) * upperalphatable / 255, 2, 0)
    #calculate the lower layer's portion of the composted picture
    ltable = Numeric.swapaxes(Numeric.swapaxes(lowerlayer[:,:,0:3], 0, 
2) * (255 - upperalphatable) / 255, 2, 0)
    return makenewpixels(ltable, utable, h, w, upperalphatable, 
loweralphatable)

    Thanks,
          Alex Schultz

Re: [Numpy-discussion] numarray: PyArrayObject supports number protocols?

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

On Tue, 2005-08-02 at 15:53, Perry Greenfield wrote:
> On Jul 31, 2005, at 11:56 PM, Edward C. Jones wrote:
> 
> > I just saw in the docs, Section 14.2.4:
> >
> > It should be noted that unlike earlier versions of numarray, the 
> > present PyArrayObject structure is a first class python object, with 
> > full support for the number protocols in C.
> >
> > Does this mean that I can add two numarrays in C using "PyNumber_Add"?

Yes.   It should be noted that the numarray implementation of the number
protocol is (still) in Python so there are issues with "atomicity" and
the global interpreter lock just as there are with other Python
callbacks from C. 

The documentation is referring to early versions of numarray where the
C-API's C-representation of an array was not a Python object at all.

Regards,
Todd

> Todd is away for a few days, and I haven't found the actual support for 
> this in the code, so I'm going to wait until he's back for a definitive 
> answer.
> 
> Perry

Re: [Numpy-discussion] numarray: PyArrayObject supports number protocols?

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

On Jul 31, 2005, at 11:56 PM, Edward C. Jones wrote:

> I just saw in the docs, Section 14.2.4:
>
> It should be noted that unlike earlier versions of numarray, the 
> present PyArrayObject structure is a first class python object, with 
> full support for the number protocols in C.
>
> Does this mean that I can add two numarrays in C using "PyNumber_Add"?
>
Todd is away for a few days, and I haven't found the actual support for 
this in the code, so I'm going to wait until he's back for a definitive 
answer.

Perry

Re: [Numpy-discussion] numarray: Does NA_NewArray return a new reference?

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

On Aug 1, 2005, at 11:40 PM, Edward C. Jones wrote:

> Do functions such as NA_NewArray return a new reference? Then I should 
> Py_XDECREF them when I am finished with them?

Yes, yes.

Perry

Re: [Numpy-discussion] exp

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

Pieter Dumon wrote:
> Hi,
> 
> I'm having a problem with exp():
> 
>  >>>import Numeric
>  >>>a = Numeric.array([-800+0j])*Numeric.ones(10)
>  >>>Numeric.exp(a)
> 
> results in"OverflowError: math range error"
> 
> I had expected to get the cmath.exp() result:
> 
>  >>> import cmath
>  >>> cmath.exp(-800+0j)
> 0j
> 
> 
> anyone knows what I'm doing wrong ?

Numeric doesn't underflow to zero silently, nor does it offer a way to control 
the fpu's exception bits directly.  I believe that numarray does offer such 
facilities.

For exponentials of real arguments, I've overridden exp() with my own version:

def exp_safe(x):
     """Compute exponentials which safely underflow to zero.

     Slow but convenient to use. Note that NumArray will introduce proper
     floating point exception handling with access to the underlying
     hardware."""

     if type(x) is ArrayType:
         return exp(clip(x,exp_safe_MIN,exp_safe_MAX))
     else:
         return math.exp(x)

You can modify this to work with complex inputs.

Best,

f

[Numpy-discussion] exp

[Pieter D. <Pie...@in...>]

Hi,

I'm having a problem with exp():

 >>>import Numeric
 >>>a = Numeric.array([-800+0j])*Numeric.ones(10)
 >>>Numeric.exp(a)

results in"OverflowError: math range error"

I had expected to get the cmath.exp() result:

 >>> import cmath
 >>> cmath.exp(-800+0j)
0j


anyone knows what I'm doing wrong ?

Pieter

[Numpy-discussion] ANN: matplotlib 0.83.2

[John H. <jdh...@ac...>]

This is a summary of recent developments in matplotlib since 0.80.
For detailed notes, see http://matplotlib.sf.net/whats_new.html,
http://matplotlib.sf.net/CHANGELOG and
http://matplotlib.sf.net/API_CHANGES

== Whats New ==

matplotlib wiki: this was just launched a few days ago and only has
  two entries to date, but we hope this will grow into a useful site
  with tutorials, howtos, installation notes, recipes, etc.  Please
  contribute!  Thanks to scipy.org and Enthought for hosting.
  http://www.scipy.org/wikis/topical_software/MatplotlibCookbook

CocoaAgg: New CocoaAgg backend for native GUI on OSX, 10.3 and 10.4
  compliant, contributed by Charles Moad.

TeX support : Now you can (optionally) use TeX to handle all of the
  text elements in your figure with the rc param text.usetex in the
  antigrain and postscript backends; see
  http://www.scipy.org/wikis/topical_software/UsingTex.  Thanks to
  Darren Dale for hard work on the TeX support.

Reorganized config files: Made HOME/.matplotlib the new config dir
  where the matplotlibrc file, the ttf.cache, and the tex.cache live.
  Your .matplotlibrc file, if you have one, should be renamed to
  .matplotlib/matplotlibrc.

Masked arrays: Support for masked arrays in line plots, pcolor and
  contours.  Thanks Eric Firing and Jeffrey Whitaker.

New image resize options interpolation options.  See help(imshow) for
  details, particularly the interpolation, filternorm and filterrad
  kwargs.  New values for the interp kwarg are:
        
    'nearest', 'bilinear', 'bicubic', 'spline16', 'spline36',
    'hanning', 'hamming', 'hermite', 'kaiser', 'quadric', 'catrom',
    'gaussian', 'bessel', 'mitchell', 'sinc', 'lanczos', 'blackman'

Byte images: Much faster imaeg loading for MxNx4 or MxNx3 UInt8
  images, which bypasses the memory and CPU intensive integer/floating
  point conversions.  Thanks Nicolas Girard.

Fast markers on win32: The marker cache optimization is finally
  available for win32, after an agg bug was found and fixed (thanks
  Maxim!).  Line marker plots should be considerably faster now on
  win32.

Qt in ipython/pylab: You can now use qt in ipython pylab mode.  Thanks
  Fernando Perez and the Orsay team!

Agg wrapper proper: Started work on a proper agg wrapper to expose
  more general agg functionality in mpl.  See examples/agg_test.py.
  Lots of wrapping remains to be done.

Subplot configuration: There is a new toolbar button on
  GTK*, WX* and TkAgg to launch the subplot configuration tool.

GUI neutral widgets: Matplotlib now has cross-GUI widgets (buttons,
  check buttons, radio buttons and sliders).  See
  examples/widgets/*.py and
  http://matplotlib.sf.net/screenshots.html#slider_demo.  This makes
  it easier to create interactive figures that run across backends.

Full screen mode in GTK*: Use 'f' to toggle full screen mode in the
  GTK backends.  Thanks Steve Chaplin.

Downloads available from http://matplotlib.sf.net

[Numpy-discussion] numarray: Does NA_NewArray return a new reference?

[Edward C. J. <edc...@co...>]

Do functions such as NA_NewArray return a new reference? Then I should 
Py_XDECREF them when I am finished with them?

[Numpy-discussion] numarray: PyArrayObject supports number protocols?

[Edward C. J. <edc...@co...>]

I just saw in the docs, Section 14.2.4:

It should be noted that unlike earlier versions of numarray, the present 
PyArrayObject structure is a first class python object, with full 
support for the number protocols in C.

Does this mean that I can add two numarrays in C using "PyNumber_Add"?

Re: [Numpy-discussion] LAPACK/BLAS for Fedora core 4 i386 ?

[Piotr L. <lus...@cs...>]

Chris Barker wrote:
> Darren Dale wrote:
> 
>> Maybe I don't understanding something, but isn't the point of ATLAS 
>> that the libraries are tuned at compile time for your specific setup?
> 
> 
> yes, but the binaries I downloaded are for the P4 processor, so I'm not 
> sure how much more specific I can get. I'm going to give it a try.

Unfortunately, you have to get very specific to get the most out of
Atlas. The two things that come to mind are:

- cache size which differs across various Pentium 4s/Xeons
- clock speed

The former means that you have to block operations on your matrices
in the right way so you keep data in each level of memory hierarchy
as long as possible.

Clock speed matters because it introduces varying memory latencies
so, for example, you might not be prefetching data at the right rate.

That's why I usually compile Atlas without any builtin presets even
though it takes very long. However, I also try the prebuilt binaries
to make sure that Clint (Atlas' author) didn't turn some secret
knob that I don't know about.

Piotr

Re: [Numpy-discussion] LAPACK/BLAS for Fedora core 4 i386 ?

[Matthew B. <mat...@gm...>]

Hi,=20

> yes, but the binaries I downloaded are for the P4 processor, so I'm not
> sure how much more specific I can get. I'm going to give it a try.

There is some tuning that is specific to the cache, which might change
things a bit.  Is it possible your test code uses NaNs at some point?=20
That will result in a huge slowdown on the P4 with the default ATLAS
binaries:

http://www.mrc-cbu.cam.ac.uk/Imaging/Common/spm_intel_tune.shtml#nan_proble=
m

Matthew

Re: [Numpy-discussion] LAPACK/BLAS for Fedora core 4 i386 ?

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

Darren Dale wrote:
> Maybe I don't understanding something, but isn't the point of ATLAS that the 
> libraries are tuned at compile time for your specific setup?

yes, but the binaries I downloaded are for the P4 processor, so I'm not 
sure how much more specific I can get. I'm going to give it a try.

This does bring up a point, however. Why is lapack usually linked 
statically? I usually link statically so that I can move applications to 
a different system without worrying about what libraries are installed 
there. However, with lapack/blas, you want to use a library compiled for 
that particular machine, so it seems to make more sense to use dynamic 
ones. Besides, it would be easier to compare performance if all I had to 
do was drop a new *.so in place.

-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

Chr...@no...

Re: [Numpy-discussion] LAPACK/BLAS for Fedora core 4 i386 ?

[Darren D. <dd...@co...>]

On Friday 29 July 2005 12:22 pm, Chris Barker wrote:
> > To find out you might have to look at the LAPACK functions you are
> > using and compare them against the ones provided by ATLAS.
>
> Well, I'm testing using LinearAlgebra.solve_linear_equations() from
> Numeric (and numarray). The reason I'm wondering is that on my last
> machine, a 1ghz PIII laptop running Gentoo, using the Gentoo provided
> atlas/lapack, I got a 6-7 times speed up over lapack_lite.
>
> On my new machine, a 2GHz Pentium M laptop running FC4, I got about a 2
> times speed-up, which is nice, but not nearly as impressive.
>
> Another possible issue is that I used pre-complied binaries form the
> atlas site, which are a bit old, maybe I should compile myself. Any
> thoughts?

Maybe I don't understanding something, but isn't the point of ATLAS that the 
libraries are tuned at compile time for your specific setup?

-- 

Darren