Re: [Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1

On Tue, Jun 21, 2011 at 3:52 PM, Ralf Gommers wrote: > > > On Tue, Jun 21, 2011 at 10:05 PM, Ralf Gommers > wrote: >> >> >> On Tue, Jun 21, 2011 at 4:38 PM, Bruce Southey wrote: >>> >>> On 06/21/2011 01:01 AM, Ralf Gommers wrote: >>> >>> On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey >>> wrote:

[Numpy-discussion] ANN: ETS 4.0 released

Hello, I am happy to announce the release of ETS 4.0. This is the first major release of the Enthought Tool Suite in almost three years. This release removes the 'enthought' namespace from all projects. For example: from enthought.traits.api import HasTraits is now simply:: from trai

Re: [Numpy-discussion] fast SSD

On Tue, Jun 21, 2011 at 7:09 PM, Alex Flint wrote: > Is there a fast way to compute an array of sum-of-squared-differences > between a (small) K x K array and all K x K sub-arrays of a larger array? > (i.e. each element x,y in the output array is the SSD between the small > array and the sub-arr

Re: [Numpy-discussion] fast SSD

On Tue, Jun 21, 2011 at 5:09 PM, Alex Flint wrote: > Is there a fast way to compute an array of sum-of-squared-differences > between a (small)  K x K array and all K x K sub-arrays of a larger array? > (i.e. each element x,y in the output array is the SSD between the small > array and the sub-arra

[Numpy-discussion] fast SSD

Is there a fast way to compute an array of sum-of-squared-differences between a (small) K x K array and all K x K sub-arrays of a larger array? (i.e. each element x,y in the output array is the SSD between the small array and the sub-array (x:x+K, y:y+K) My current implementation loops over each

Re: [Numpy-discussion] replacing the mechanism for dispatching ufuncs

On Tue, Jun 21, 2011 at 1:46 PM, Darren Dale wrote: > On Tue, Jun 21, 2011 at 2:28 PM, Charles R Harris > wrote: > > > > > > On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe wrote: > >> > >> On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris > >> wrote: > >>> > >>> > >>> On Mon, Jun 20, 2011 at 12

Re: [Numpy-discussion] replacing the mechanism for dispatching ufuncs

On Tue, Jun 21, 2011 at 1:28 PM, Charles R Harris wrote: > > > On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe wrote: > >> On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe wrote: >>> NumPy has

Re: [Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1

On Tue, Jun 21, 2011 at 10:05 PM, Ralf Gommers wrote: > > > On Tue, Jun 21, 2011 at 4:38 PM, Bruce Southey wrote: > >> ** >> On 06/21/2011 01:01 AM, Ralf Gommers wrote: >> >> >> >> On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey wrote: >> >> >>> So what is the actual name of the multiarray shared

Re: [Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1

On Tue, Jun 21, 2011 at 4:38 PM, Bruce Southey wrote: > ** > On 06/21/2011 01:01 AM, Ralf Gommers wrote: > > > > On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey wrote: > >> On Mon, Jun 20, 2011 at 2:43 PM, Ralf Gommers >> wrote: >> > >> > >> > On Mon, Jun 20, 2011 at 8:50 PM, Bruce Southey >>

Re: [Numpy-discussion] (cumsum, broadcast) in (numexpr, weave)

Apologies, intended to send this to the scipy list. On Tue, Jun 21, 2011 at 2:35 PM, srean wrote: > Hi All, > >  is there a fast way to do cumsum with numexpr ? I could not find it, > but the functions available in numexpr does not seem to be > exhaustively documented, so it is possible that I mi

[Numpy-discussion] (cumsum, broadcast) in (numexpr, weave)

Hi All, is there a fast way to do cumsum with numexpr ? I could not find it, but the functions available in numexpr does not seem to be exhaustively documented, so it is possible that I missed it. Do not know if 'sum' takes special arguments that can be used. To try another track, does numexpr o

Re: [Numpy-discussion] replacing the mechanism for dispatching ufuncs

On Tue, Jun 21, 2011 at 12:46 PM, Darren Dale wrote: > On Tue, Jun 21, 2011 at 2:28 PM, Charles R Harris > wrote: > > > > > > On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe wrote: > >> > >> On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris > >> wrote: > >>> > >>> > >>> On Mon, Jun 20, 2011 at 1

Re: [Numpy-discussion] replacing the mechanism for dispatching ufuncs

On Tue, Jun 21, 2011 at 2:28 PM, Charles R Harris wrote: > > > On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe wrote: >> >> On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris >> wrote: >>> >>> >>> On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe wrote: NumPy has a mechanism built in to allow

Re: [Numpy-discussion] fast numpy i/o

Robert Kern wrote: > https://raw.github.com/numpy/numpy/master/doc/neps/npy-format.txt Just a note. From that doc: """ HDF5 is a complicated format that more or less implements a hierarchical filesystem-in-a-file. This fact makes satisfying some of the Requirements difficult. To

Re: [Numpy-discussion] fast numpy i/o

Hi, I have been using h5py a lot (both on windows and Mac OSX) and can only recommend it- haven't tried the other options though Cheers, Simon On Tue, Jun 21, 2011 at 8:24 PM, Derek Homeier < de...@astro.physik.uni-goettingen.de> wrote: > On 21.06.2011, at 7:58PM, Neal Becker wrote: >

Re: [Numpy-discussion] replacing the mechanism for dispatching ufuncs

On Tue, Jun 21, 2011 at 11:57 AM, Mark Wiebe wrote: > On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe wrote: >> >>> NumPy has a mechanism built in to allow subclasses to adjust or override >>> aspect

Re: [Numpy-discussion] fast numpy i/o

On 21.06.2011, at 7:58PM, Neal Becker wrote: > I think, in addition, that hdf5 is the only one that easily interoperates > with > matlab? > > speaking of hdf5, I see: > > pyhdf5io 0.7 - Python module containing high-level hdf5 load and save > functions. > h5py 2.0.0 - Read and write HDF5 fi

Re: [Numpy-discussion] fast numpy i/o

Neal Becker wrote: >> I'm wondering what are good choices for fast numpy array serialization? >> >> mmap: fast, but I guess not self-describing? >> hdf5: ? >> pickle: self-describing, but maybe not fast? >> others? > > I think, in addition, that hdf5 is the only one that easily interoperates > wi

Re: [Numpy-discussion] what python module to handle csv?

I am a huge fan of rec2csv and csv2rec, which might not technically be part of numpy, and can be found in pylab or the matplotlib.mlab module. --Abie From: numpy-discussion-boun...@scipy.org [mailto:numpy-discussion-boun...@scipy.org] On Behalf Of Olivier Delalleau Sent: Wednesday, June 15, 20

Re: [Numpy-discussion] replacing the mechanism for dispatching ufuncs

On Tue, Jun 21, 2011 at 12:36 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe wrote: > >> NumPy has a mechanism built in to allow subclasses to adjust or override >> aspects of the ufunc behavior. While this goal is important, this mecha

Re: [Numpy-discussion] fast numpy i/o

Neal Becker wrote: > I'm wondering what are good choices for fast numpy array serialization? > > mmap: fast, but I guess not self-describing? > hdf5: ? Should be pretty fast, and self describing -- advantage of being a standard. Disadvantage is that it requires an hdf5 library, which can b a pa

Re: [Numpy-discussion] fast numpy i/o

On Tue, Jun 21, 2011 at 12:49, Neal Becker wrote: > I'm wondering what are good choices for fast numpy array serialization? > > mmap: fast, but I guess not self-describing? > hdf5: ? > pickle: self-describing, but maybe not fast? > others? NPY: http://docs.scipy.org/doc/numpy/reference/generated/

Re: [Numpy-discussion] fast numpy i/o

Neal Becker wrote: > I'm wondering what are good choices for fast numpy array serialization? > > mmap: fast, but I guess not self-describing? > hdf5: ? > pickle: self-describing, but maybe not fast? > others? I think, in addition, that hdf5 is the only one that easily interoperates with matlab?

[Numpy-discussion] fast numpy i/o

I'm wondering what are good choices for fast numpy array serialization? mmap: fast, but I guess not self-describing? hdf5: ? pickle: self-describing, but maybe not fast? others? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.sc

Re: [Numpy-discussion] poor performance of sum with sub-machine-word integer types

On Jun 21, 2011, at 1:16 PM, Charles R Harris wrote: > It's because of the type conversion sum uses by default for greater precision. Aah, makes sense. Thanks for the detailed explanations and timings! ___ NumPy-Discussion mailing list NumPy-Discussion@

Re: [Numpy-discussion] replacing the mechanism for dispatching ufuncs

On Mon, Jun 20, 2011 at 12:32 PM, Mark Wiebe wrote: > NumPy has a mechanism built in to allow subclasses to adjust or override > aspects of the ufunc behavior. While this goal is important, this mechanism > only allows for very limited customization, making for instance the masked > arrays unable

Re: [Numpy-discussion] poor performance of sum with sub-machine-word integer types

On Tue, Jun 21, 2011 at 11:17 AM, Keith Goodman wrote: > On Tue, Jun 21, 2011 at 9:46 AM, Zachary Pincus > wrote: > > Hello all, > > > > As a result of the "fast greyscale conversion" thread, I noticed an > anomaly with numpy.ndararray.sum(): summing along certain axes is much > slower with sum(

Re: [Numpy-discussion] poor performance of sum with sub-machine-word integer types

On Tue, Jun 21, 2011 at 9:46 AM, Zachary Pincus wrote: > Hello all, > > As a result of the "fast greyscale conversion" thread, I noticed an anomaly > with numpy.ndararray.sum(): summing along certain axes is much slower with > sum() than versus doing it explicitly, but only with integer dtypes a

Re: [Numpy-discussion] poor performance of sum with sub-machine-word integer types

On Tue, Jun 21, 2011 at 10:46 AM, Zachary Pincus wrote: > Hello all, > > As a result of the "fast greyscale conversion" thread, I noticed an anomaly > with numpy.ndararray.sum(): summing along certain axes is much slower with > sum() than versus doing it explicitly, but only with integer dtypes an

[Numpy-discussion] poor performance of sum with sub-machine-word integer types

Hello all, As a result of the "fast greyscale conversion" thread, I noticed an anomaly with numpy.ndararray.sum(): summing along certain axes is much slower with sum() than versus doing it explicitly, but only with integer dtypes and when the size of the dtype is less than the machine word. I c

Re: [Numpy-discussion] תשובה: faster in1d() for monotonic case?

I'm not quite sure how to use searchsorted to get the output I need (e.g., the length of the output needs to be as long as large_array). But in any case it says it uses binary search, so it would seem to be an O( n * log( n ) ) solution, whereas I'm hoping for an O( n ) solution.

Re: [Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1

On 06/21/2011 01:01 AM, Ralf Gommers wrote: On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey > wrote: On Mon, Jun 20, 2011 at 2:43 PM, Ralf Gommers mailto:ralf.gomm...@googlemail.com>> wrote: > > > On Mon, Jun 20, 2011 at 8:50 PM, Bruce Southey

Re: [Numpy-discussion] Controlling endianness of ndarray.tofile()

Thanks Gary, that works. Out of interest I timed it: http://pastebin.com/HA4Qn9Ge On average the swapping incurred a 0.04 second penalty (compared with 1.5 second total run time) for a 4096x4096 array of 64-bit reals. So there is no real penalty. Cheers, Ben On Tue, Jun 21, 2011 at 8:37 PM, gar

Re: [Numpy-discussion] Controlling endianness of ndarray.tofile()

Hi Ben, based on this example I suspect the way to do it is with numpy.byteswap() and numpy.tofile() >From > we can do >>> A = np.array([1, 256, 8

[Numpy-discussion] תשובה: faster in1d() for monotonic case?

Did you try searchsorted? Nadav מאת: numpy-discussion-boun...@scipy.org [mailto:numpy-discussion-boun...@scipy.org] בשם Michael Katz נשלח: Tuesday, June 21, 2011 10:06 אל: Discussion of Numerical Python נושא: [Numpy-discussion] faster in1d() for monotonic case?

[Numpy-discussion] Controlling endianness of ndarray.tofile()

Hi, On my system (Intel Xeon, Windows 7 64-bit), ndarray.tofile() outputs in little-endian. This is a bit inconvenient, since everything else I do is in big-endian. Unfortunately, scipy.io.write_arrray() is deprecated, and I can't find any other routines that write pure raw binary. Are there any o

[Numpy-discussion] faster in1d() for monotonic case?

The following call is a bottleneck for me:     np.in1d( large_array.field_of_interest, values_of_interest ) I'm not sure how in1d() is implemented, but this call seems to be slower than O(n) and faster than O( n**2 ), so perhaps it sorts the values_of_interest and does a binary search for each