numpy-discussion

Re: [Numpy-discussion] Numpy Benchmarking

[<jo...@st...>]

Hi,

 [TO]: NumPy uses Numeric's old wrapper to lapack algorithms. 
 [TO]: 
 [TO]: SciPy uses it's own f2py-generated wrapper (it doesn't rely on the
 [TO]: NumPy wrapper).
 [TO]: 
 [TO]: The numpy.dual library exists so you can use the SciPy calls if the 
 [TO]: person has SciPy installed or the NumPy ones otherwise.  It exists 
 [TO]: precisely for the purpose of seamlessly taking advantage of 
 [TO]: algorithms/interfaces that exist in NumPy but  are improved in SciPy.

This strikes me as a little bit odd. Why not just provide the best-performing 
function to both SciPy and NumPy? Would NumPy be more difficult to install
if the SciPy algorithm for inv() was incorporated?

Joris




Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Numpy-discussion] Numpy Benchmarking

[Robert K. <rob...@gm...>]

jo...@st... wrote:
> Hi,
> 
>  [TO]: NumPy uses Numeric's old wrapper to lapack algorithms. 
>  [TO]: 
>  [TO]: SciPy uses it's own f2py-generated wrapper (it doesn't rely on the
>  [TO]: NumPy wrapper).
>  [TO]: 
>  [TO]: The numpy.dual library exists so you can use the SciPy calls if the 
>  [TO]: person has SciPy installed or the NumPy ones otherwise.  It exists 
>  [TO]: precisely for the purpose of seamlessly taking advantage of 
>  [TO]: algorithms/interfaces that exist in NumPy but  are improved in SciPy.
> 
> This strikes me as a little bit odd. Why not just provide the best-performing 
> function to both SciPy and NumPy? Would NumPy be more difficult to install
> if the SciPy algorithm for inv() was incorporated?

That's certainly the case for the FFT algorithms. Scipy wraps more (and more 
complicated) FFT libraries that are faster than FFTPACK.

Most of the linalg functionality should probably be wrapping the same routines 
if an optimized LAPACK is available. However, changing the routine used in numpy 
in the absence of an optimized LAPACK would require reconstructing the f2c'ed 
lapack_lite library that we include with the numpy source. That hasn't been 
touched in so long that I would hesitate to do so. If you are willing to do the 
work and the testing to ensure that it still works everywhere, we'd probably 
accept the change.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] Numpy Benchmarking

[David M. C. <co...@ph...>]

On Wed, 28 Jun 2006 03:22:28 -0500
Robert Kern <rob...@gm...> wrote:

> jo...@st... wrote:
> > Hi,
> > 
> >  [TO]: NumPy uses Numeric's old wrapper to lapack algorithms. 
> >  [TO]: 
> >  [TO]: SciPy uses it's own f2py-generated wrapper (it doesn't rely on the
> >  [TO]: NumPy wrapper).
> >  [TO]: 
> >  [TO]: The numpy.dual library exists so you can use the SciPy calls if
> > the [TO]: person has SciPy installed or the NumPy ones otherwise.  It
> > exists [TO]: precisely for the purpose of seamlessly taking advantage of 
> >  [TO]: algorithms/interfaces that exist in NumPy but  are improved in
> > SciPy.
> > 
> > This strikes me as a little bit odd. Why not just provide the
> > best-performing function to both SciPy and NumPy? Would NumPy be more
> > difficult to install if the SciPy algorithm for inv() was incorporated?
> 
> That's certainly the case for the FFT algorithms. Scipy wraps more (and
> more complicated) FFT libraries that are faster than FFTPACK.
> 
> Most of the linalg functionality should probably be wrapping the same
> routines if an optimized LAPACK is available. However, changing the routine
> used in numpy in the absence of an optimized LAPACK would require
> reconstructing the f2c'ed lapack_lite library that we include with the
> numpy source. That hasn't been touched in so long that I would hesitate to
> do so. If you are willing to do the work and the testing to ensure that it
> still works everywhere, we'd probably accept the change.

Annoying to redo (as tracking down *good* LAPACK sources is a chore), but
hardly as bad as it was.

I added the scripts I used to generated lapack_lite.c et al to
numpy/linalg/lapack_lite in svn. These are the same things that were used to
generate those files in recent versions of Numeric (which numpy uses). You
only need to specify the top-level routines; the scripts find the
dependencies.

I'd suggest using the source for LAPACK that Debian uses; the maintainer, Camm
Maguire, has done a bunch of work adding patches to fix routines that have
been floating around. For instance, eigenvalues works better than before (lot
fewer segfaults).

With this, the hard part is writing the wrapper routines. If someone wants to
wrap extra routines, I can do the the lapack_lite generation for them.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] Numpy Benchmarking

[Jon W. <wr...@es...>]

>>This strikes me as a little bit odd. Why not just provide the best-performing 
>>function to both SciPy and NumPy? Would NumPy be more difficult to install
>>if the SciPy algorithm for inv() was incorporated?
>>    
>>
Having spent a few days recently trying out various different 
eigenvector routines in Lapack I would have greatly appreciated having a 
choice of which one to use from without having to create my own 
wrappers, compiling atlas and lapack under windows (ouch). I noted that 
Numeric (24.2) seemed to be converting Float32 to double meaning my 
problem no longer fits in memory, which was the motivation for the work. 
Poking around in the svn of numpy.linalg appears to find the same lapack 
routine as Numeric (dsyevd). Perhaps I miss something in the code logic? 
The divide and conquer (*evd) uses more memory than the (*ev), as well 
as a factor of 2 for float/double, hence my problem, and the reason why 
"best performing" is a hard choice. I thought matlab has a look at the 
matrix dimensions and problem before deciding what to do (eg: the \ 
operator).

Jon

Re: [Numpy-discussion] Numpy Benchmarking

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

Hi,

On Wed, 28 Jun 2006, Jon Wright wrote:

>
> >>This strikes me as a little bit odd. Why not just provide the best-performing
> >>function to both SciPy and NumPy? Would NumPy be more difficult to install
> >>if the SciPy algorithm for inv() was incorporated?
> >>
> >>
> Having spent a few days recently trying out various different
> eigenvector routines in Lapack I would have greatly appreciated having a
> choice of which one to use

which routine are you trying to use?

> from without having to create my own
> wrappers, compiling atlas and lapack under windows (ouch). I noted that
> Numeric (24.2) seemed to be converting Float32 to double meaning my
> problem no longer fits in memory, which was the motivation for the work.
> Poking around in the svn of numpy.linalg appears to find the same lapack
> routine as Numeric (dsyevd). Perhaps I miss something in the code logic?

if you can convince the code to  get ssyevd instead of dsyevd
it might do what you want>


> The divide and conquer (*evd) uses more memory than the (*ev), as well
> as a factor of 2 for float/double, hence my problem, and the reason why
> "best performing" is a hard choice. I thought matlab has a look at the
> matrix dimensions and problem before deciding what to do (eg: the \
> operator).

Hmm, this is a hard choice, which might better left
in the hands of the knowledgeable user.
(e.g., aren't the divide and conquer routines substantially faster?)

Best, Arnd

Re: [Numpy-discussion] Numpy Benchmarking

[David M. C. <co...@ph...>]

On Wed, 28 Jun 2006 10:55:36 +0200
Jon Wright <wr...@es...> wrote:

> Poking around in the svn of numpy.linalg appears to find the same lapack 
> routine as Numeric (dsyevd). Perhaps I miss something in the code logic?

It's actually *exactly* the same as the latest Numeric :-) It hasn't been
touched much.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] Numpy Benchmarking

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

jo...@st... wrote:

>Hi,
>
> [TO]: NumPy uses Numeric's old wrapper to lapack algorithms. 
> [TO]: 
> [TO]: SciPy uses it's own f2py-generated wrapper (it doesn't rely on the
> [TO]: NumPy wrapper).
> [TO]: 
> [TO]: The numpy.dual library exists so you can use the SciPy calls if the 
> [TO]: person has SciPy installed or the NumPy ones otherwise.  It exists 
> [TO]: precisely for the purpose of seamlessly taking advantage of 
> [TO]: algorithms/interfaces that exist in NumPy but  are improved in SciPy.
>
>This strikes me as a little bit odd. Why not just provide the best-performing 
>function to both SciPy and NumPy? Would NumPy be more difficult to install
>if the SciPy algorithm for inv() was incorporated?
>  
>

The main issue is that SciPy can take advantage and use Fortran code, 
but NumPy cannot as it must build without a Fortran compiler.   This is 
the primary driver to the current duality.

-Travis