Re: [Numpy-discussion] C or C++ package like NumPy?

2007-11-02 Thread Matthieu Brucher
Sorry : http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/
It has some publications written about the design it uses (iterators and
such), really well done.

Matthieu

2007/11/2, Bill Baxter [EMAIL PROTECTED]:

 On Nov 2, 2007 3:50 PM, Matthieu Brucher [EMAIL PROTECTED]
 wrote:

  You can look at Vigra (but I don't know if there is linear algebra, but
  there are views, multidimensional containers, ...).

 Thanks for the link.  Hadn't heard of that one.

 --bb
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://projects.scipy.org/mailman/listinfo/numpy-discussion




-- 
French PhD student
Website : http://miles.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] C or C++ package like NumPy?

2007-11-02 Thread Bill Baxter
Oh, I didn't realize you didn't give a link.  I just googled reflexively.

Anyway, that makes me think of the other generic image library I've
heard of -- Adobe's GIL.
Never really looked at it in much detail but checking now, it looks
like it does support N-dim images.

http://opensource.adobe.com/gil/html/gildesignguide.html#ImageSectionDG

--bb

On Nov 2, 2007 4:00 PM, Matthieu Brucher [EMAIL PROTECTED] wrote:
 Sorry : http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/
 It has some publications written about the design it uses (iterators and
 such), really well done.

 Matthieu

 2007/11/2, Bill Baxter [EMAIL PROTECTED]:
 
 
 
  On Nov 2, 2007 3:50 PM, Matthieu Brucher [EMAIL PROTECTED]
 wrote:
 
   You can look at Vigra (but I don't know if there is linear algebra, but
   there are views, multidimensional containers, ...).
 
  Thanks for the link.  Hadn't heard of that one.
 
  --bb
 
  ___
  Numpy-discussion mailing list
  Numpy-discussion@scipy.org
  http://projects.scipy.org/mailman/listinfo/numpy-discussion
 




 --
  French PhD student
 Website : http://miles.developpez.com/
 Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
 ___
 Numpy-discussion mailing list
 Numpy-discussion@scipy.org
 http://projects.scipy.org/mailman/listinfo/numpy-discussion


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] numpy FFT memory accumulation

2007-11-02 Thread Ray Schumacher
At 10:57 PM 11/1/2007, Charles R Harris wrote:
  An additional complication is that I pass the numpy (or Numeric)
  array address to the ctypes library call so that the data is placed
  directly into the array from the call. I use the if/else end wrap
  logic to determine whether I need to do a split and copy if the new
  data wraps.

OK. Hmm, I wonder if you would lose much by taking a straight forward
radix-2 fft and teaching it to use modular indices? Probably not worth the
trouble, but an fft tailored to a  ring buffer might be useful for other
things.

The problem is, I once compiled my own FFT dll to call from Python 
and it was 2x slower than FFTPACK - I'm not math-smart enough to make 
all of the caching and numerical shortcuts.  That, and Intel's 
optimized FFT is 3x faster than FFTPACK...
I may still try to do a zoom/range FFT which does not compute all 
bins, and maybe only with a sine transform, which (I think) should be 
sufficient to determine peak real frequency and maybe use fewer cycles.

Probably the easiest thing is to just copy the ring buffer out into
a linear array.

I do that for the buffer-wrap condition, while simply assigning a 
slice (no copy) to the temp array otherwise.

  I used Numeric functions for the ~40% speed increase, but I don't

I know that numarray was slow in creating small arrays, but is Numpy 
really that bad compared to Numeric?

I just saw the # of FFTs/sec go from 390 to 550 just by switching 
numpy to Numeric (Intel Core Duo). Add a timer to my previous code 
posts and see how your results look. For the mega-arrays a lot of the 
numpy developers work with it is much faster, and I now find Numeric 
is lacking many other niceties, like frombuffer().

Ray


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.503 / Virus Database: 269.15.18/1104 - Release Date: 11/1/2007 
6:47 PM


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] C or C++ package like NumPy?

2007-11-02 Thread Neal Becker
Charles R Harris wrote:

 On 11/1/07, Bill Baxter [EMAIL PROTECTED] wrote:

 Ah, ok.  Thanks.  That does look like a good example.
 I've heard of it, but never looked too closely for some reason.  I
 guess I always thought of it as the library that pioneered expression
 templates but that no one actually uses.
 
 
 I believe it is no longer maintained. I might be wrong about that, though.
 
 Chuck

It is being maintained, at least to some extent.  See:
[EMAIL PROTECTED]

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] vectorizing loops

2007-11-02 Thread Francesc Altet
A Thursday 01 November 2007, Timothy Hochberg escrigué:
 On Nov 1, 2007 7:14 AM, David M. Cooke [EMAIL PROTECTED]  
 Another issue is that numexpr is still in the scipy sandbox, so
  only those who enable it will use it (or use it through PyTables).
  One problem with moving it out is that Tim reports the compile
  times on Windows are ridiculous (20 mins!).

 While this is true at the default optimization (O2), it compiles
 reasonably quickly at O1 and I've never been able to detect a speed
 difference between versions compiled with O1 versus O2. It would
 probably be sufficient to crank back the optimization on Windows.

Yes. This has been my experience too on Windows/MSVC boxes.

  Maybe numexpr should become a
  scikit? It certainly doesn't need the rest of scipy.

Call me intrepid, but I've always felt that numexpr belongs more to 
numpy itself than scipy.  However, I agree that perhaps it should be a 
bit more polished (but not much; perhaps just adding some functions 
like, exp, log, log10... would be enough) before being integrated.  At 
any rate, Numexpr would be a extremely useful complement to NumPy.

My two cents,

-- 
0,0   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 -
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] vectorizing loops

2007-11-02 Thread Francesc Altet
A Thursday 01 November 2007, David M. Cooke escrigué:
  At any rate, we would be glad if you would like to integrate our
  patches
  in the main numexpr, as there is not much sense to have different
  implementations of numexpr (most specially when it seems that there
  are
  not much users out there).  So, count on us for any question you
  may have in this regard.

 Well, I don't have much time to work on it, but if you make sure your
 patches on the scipy Trac apply clean, I'll have a quick look at them
 and apply them. Since you've had them working in production code,
 they should be good ;-)

Well, being in production and around 1 tests (where numexpr is 
involved) in the pytables package seems a good guarantee to me too ;-)

I've attached a clean patch to ticket #529 of SciPy site:

http://scipy.org/scipy/scipy/ticket/529

However, I've committed a couple of mistakes during ticket creation, so:

  - in #529, I've uploaded the patch twice, so they are exactly the same
  - please mark #530 as invalid (duplicated)

Cheers,

-- 
0,0   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 -
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] Round 2 with Leopard+Python

2007-11-02 Thread Brian Granger
Hi,

In the process of working through the issues with sys.path on Leopard,
I have found another potential Leopard bug that is particularly nasty.

In Tiger, sudo preserves environment variables:

$ export FOO=/tmp
$ python -c import os; print os.environ['FOO']
/tmp
$ sudo python -c import os; print os.environ['FOO']
/tmp

But, in Leopard, sudo does not perserve environment variables:

$ export FOO=/tmp
$ python -c import os; print os.environ['FOO']
/tmp
$ sudo python -c import os; print os.environ['FOO']
Password:
Traceback (most recent call last):
  File string, line 1, in module
  File 
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/UserDict.py,
line 22, in __getitem__
raise KeyError(key)
KeyError: 'FOO'

This is a big problem.  First, if you have set PYTHONPATH to point
sys.path at the site-packages in /Library, this setting will be lost
when you do:

sudo python setup.py install

On another package.  I encountered this in building pytables, which
requires numpy = 1.0.3.  I had installed numpy 1.0.4, and set my
PYTHONPATH to point to it.  But, the pytables setup.py script failts
because PYTHONPATH is lost and it only sees the older (1.0.1) builtin
numpy.

Second, some setup.py scripts use environment variables to determine
how things are built, find other dependencies, etc.  Currently, this
will fail on Leopard if such packages are installed into locations
that require sudo.  I haven't tried it yet, but I expect that this
will also hold true for other python installations.  The behavior also
shows up with ruby on Leopard.

The solution currently is to install all packages to locations that
don't require sudo to write to.  I will file a bug report, but until
the bug is fixed, we should explore putting a note on the numpy/scipy
site - and even possibly on the python.org site to describe the
problem and its workaround.

Brian
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] weird numpy/pickle problem

2007-11-02 Thread Neil Martinsen-Burrell
On 11/2/07 12:00, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

 Date: Fri, 2 Nov 2007 12:58:33 -0400
 From: Brian Blais [EMAIL PROTECTED]
 Subject: [Numpy-discussion] weird numpy/pickle problem
 To: numpy-discussion@scipy.org

 I boiled it down to the code below.  Can anyone reproduce (or not)
 this error?

Works for me on OS X 10.4.9, Python 2.5.0, numpy 1.0.4dev3977.

-Neil

-- 
The theory of probabilities is at bottom nothing but common sense
reduced to calculus.
   -- Pierre Simon de Laplace

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] weird numpy/pickle problem

2007-11-02 Thread Stefan van der Walt
On Fri, Nov 02, 2007 at 12:58:33PM -0400, Brian Blais wrote:
 I encountered a peculiar numpy and pickle problem.  My version:
 
 Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04)  Mac OS X Tiger
 In [2]:numpy.__version__
 Out[2]:'1.0.4.dev3869'
 
 I pickle a matrix, and reload it.  Some operations work ok, but others give a
 hardware error and a crash!
 
 I boiled it down to the code below.  Can anyone reproduce (or not)
 this error?

This ticket looks similar:

http://projects.scipy.org/scipy/numpy/ticket/551

Cheers
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion