[Numpy-discussion] Support for understand ctypes data-types now in SVN

The NumPy dtype command now understands ctypes data-types including derived structures and arrays. This means you can specify data-types using ctypes method of building structures and pass those classes whenever NumPy expects a data-type object. Simple example: import ctypes as ct import num

Re: [Numpy-discussion] Support for understand ctypes data-types now in SVN

Stefan van der Walt wrote: >On Fri, Nov 17, 2006 at 12:43:45PM -0700, Travis Oliphant wrote: > > >>The NumPy dtype command now understands ctypes data-types including >>derived structures and arrays. >> >>This means you can specify data-types using ctypes met

Re: [Numpy-discussion] mysql -> record array

John Hunter wrote: >> "Erin" == Erin Sheldon <[EMAIL PROTECTED]> writes: >> > > >Erin> The question I have been asking myself is "what is the >Erin> advantage of such an approach?". It would be faster, but by > > In the use case that prompted this message, the pull

Re: [Numpy-discussion] mysql -> record array

Erin Sheldon wrote: > Hi Travis - > > That is an impressive speed increase. Why is w/o dtype taking > so much longer? Is this just from determining elements sizes and > counts? > If you don't specify the data-type, then the auto-discovery algorithm looks at each element in the nested sequence

Re: [Numpy-discussion] int32 twice in sctypes?

Matthew Brett wrote: >Hi, > >I was a bit confused by this on 32 bit linux: > >In [30]:sctypes['int'] >Out[30]: >[, > , > , > , > ] > >Is it easy to explain the two entries for int32 here? I notice there >is only one int32 entry for the same test on my 64 bit system. > > > The mapping from c-typ

Re: [Numpy-discussion] can int and float exists in one array?(about difference in indexing Matlab matrix and Numpy array)

Zhang Sam wrote: > Thanks for so many replies. > > In fact, I want to use several arrays to store the original data from > a practical project. In every arrays, two or three column will be > store the index. The main computation is still on matrices(float type) > which is built from the origi

Re: [Numpy-discussion] ScientificPython with NumPy

[EMAIL PROTECTED] wrote: >On 24.11.2006, at 19:04, [EMAIL PROTECTED] wrote: > > > >>Those who would like to test-drive ScientificPython with NumPy can do >>so now: just download version 2.7.1 from >> >> http://sourcesup.cru.fr/ >> >> > >Version 2.7.2 now, after the first bug fix: it wou

Re: [Numpy-discussion] dtype attributes of scalar types

Matthew Brett wrote: >Hi, > >Would it be easy and / or sensible for - say - int32.itemsize to >return the same as dtype(int32).itemsize, rather than the 'itemsize' of 'numpy.generic' objects> that it returns at the moment? > > > You can do int32(0).itemsize. Getting the itemsize attribute to "d

Re: [Numpy-discussion] fromiter and objects

Tim Hochberg wrote: >things are often not as easy as they appear, the real reason I'm writing >is this comment that explains why object arrays are disallowed in >fromiter (multiarraymodule.c::PyArray_:FromIter) > >/* We would need to alter the memory RENEW code to decrement any >

Re: [Numpy-discussion] Wanted: Numeric/NumPy compatible array creation expression

[EMAIL PROTECTED] wrote: > I am looking for a way to create an array of the same type as another > given array (but of different shape) that works both with Numeric and > NumPy without being unreasonably slow. In other words, I am looking > for a a replacement for the expression > > arr

Re: [Numpy-discussion] seting the dtype for where...

Chris Barker wrote: > Hi all, > > I'd like to set the data type for what numpy.where creates. For example: > > import numpy as N > > N.where(a >= 5, 5, 0) > > creates an integer array, which makes sense. > > N.where(a >= 5, 5.0, 0) > > creates a float64 array, which also makes sense, but I'd like a

Re: [Numpy-discussion] problems installing NumPy on OSX

> It seems running from the source dir has been the main problem all > along. It works fine outside (I guess). > > I get one error in the test Steve recommends though. But hey, 519 out > of 520 ain't so bad, is it? > Don't worry about the failing test. It's a bad test on your platform.

Re: [Numpy-discussion] Resizing without allocating additional memory

David Huard wrote: > Hi, > > I have fortran subroutines wrapped with f2py that take arrays as > arguments, and I often need to use resize(a, N) to pass an array of > copies of an element. The resize call , however, is becoming the speed > bottleneck, so my question is: > Is it possible to creat

Re: [Numpy-discussion] Overlapping copy with object_ arrays

James Flowers wrote: > Hello, > > Having a problem with overlapping copies. Memory being freed twice > ??? See below: Thanks for the test. This problem is fixed and will be checked into SVN as soon as I can figure out why I'm not able to access SVN from my work machine. The problem is tha

Re: [Numpy-discussion] pickling arrays: numpy 1.0 can't unpickle numpy 1.0.1

Emanuele Olivetti wrote: > I'm running numpy 1.0 and 1.0.1 on several hosts and > today I've found that pickling arrays in 1.0.1 generates > problems to 1.0. An example: > --- numpy 1.0.1 --- > import numpy > import pickle > a = numpy.array([1,2,3]) > f=open('test1.pickle','w') > pickle.dump(a,f) >

Re: [Numpy-discussion] installation error in cygwin

Wei wrote: > > Hi, > > I just got my new intel core duo laptop. So I downloaded the new > cygwin (including everything) but couldn’t get the numarray or numpy > modules installed correctly. I always got the following error. Can > some one help? > > Many thanks! > > Wei > > python setup.py instal

Re: [Numpy-discussion] Definition of correlation, correlate and so on ?

> > On 12/12/06, *David Cournapeau* <[EMAIL PROTECTED] > > wrote: > > Hi, > > I am polishing some code to compute autocorrelation using fft, and > when testing the code against numpy.correlate, I realised that I > am not > sure about the definitio

Re: [Numpy-discussion] fromfile and tofile access with a tempfile.TemporaryFile()

Tim Hirzel wrote: >Good thought Chris, >Normal reading and writing does seem to work. .. >But, my friend Daniel figured out a workaround when I asked to confirm >this behavior on his windows setup (and it is does behave the same for >him). The first clue was this: > > >>> f = tempfile.Temporar

Re: [Numpy-discussion] slow numpy.clip ?

David Cournapeau wrote: > Robert Kern wrote: > >> Looking at the code, it's certainly not surprising that the current >> implementation of clip() is slow. It is a direct numpy C API translation of >> the >> following (taken from numarray, but it is the same in Numeric): >> >> >> def clip(m, m_m

Re: [Numpy-discussion] slow numpy.clip ?

Robert Kern wrote: > David Cournapeau wrote: > > >> Basically, at least from those figures, both versions are pretty >> similar, and not worth improving much anyway for matplotlib. There is >> something funny with numpy version, though. >> > > Looking at the code, it's certainly not surpr

Re: [Numpy-discussion] slow numpy.clip ?

> My question is then: is there any plan to change this ? If not, is > this > for some reasons I don't see, or is this just because of lack of > manpower ? > > > I raised the possibility of breaking up the files before and Travis > was agreeable to the idea. It is still in the bac

Re: [Numpy-discussion] slow numpy.clip ?

David Cournapeau wrote: > en I went back to home, I started taking a close look a numpy/core C > sources, with the help of the numpy ebook. The huge source files make it > really difficult for me to follow some things: I was wondering if there > is some rationale behind it, or if this is just a

Re: [Numpy-discussion] Profiling numpy ? (parts written in C)

Francesc Altet wrote: >seems to tell us that memmove/memcopy are not called at all, but >instead the DOUBLE_copyswap function. This is in fact an apparence, >because if we look at the code of DOUBLE_copyswap (found in >arraytypes.inc.src): > >@[EMAIL PROTECTED] (void *dst, void *src, int swap, voi

Re: [Numpy-discussion] PyArray_DIMS problem

Gennan Chen wrote: > Hi! > > I have problem with this function call under FC6 X86_64 for my own > numpy extension > > printf("\n %d %d %d", > PyArray_DIM(imgi,0),PyArray_DIM(imgi,1),PyArray_DIM(imgi,2)) > > it gave me > > 166 256 256 > > if I tried: > > int *dim; > dim = PyArray_DIMS(imgi) > p

Re: [Numpy-discussion] Newbie Question, Probability

Mark Janikas wrote: > Thanks for all the input so far. The only thing that seems odd about > the omission of probability or quantile functions in NumPy is that all > the random number generators are present in RandomArray. A big part of the issue is that getting many of those pdfs into NumPy wou

Re: [Numpy-discussion] Newbie Question, Probability

Christopher Barker wrote: > It can be a pain to build this kind of thing on OS-X, as Apple has not > supported a Fortran compiler yet, but it can (and has) been done. IN > fact, the Mac is a great target for pre-built binaries as there is only > a small variety of hardware to support, and Apple

Re: [Numpy-discussion] Newbie Question, Probability

Sven Schreiber wrote: > Robert Kern schrieb: > >> Pierre GM wrote: >> > So, to put it "pointedly" (if that's the right word...?): > Numpy should not get small functions from scipy -> because the size of > scipy doesn't matter -> because scipy's modules will be installable as > add-ons separ

Re: [Numpy-discussion] repr of bool matrix

Keith Goodman wrote: > Bool matrices and arrays don't line up when you display them because > False has 5 letters and True has 4. > > After several columns it can become impossible to tell which column an > element belongs to. > > Could the repr of bool matrices print 'True ' instead of 'True'? >

Re: [Numpy-discussion] nested recarrays

Matthew Koichi Grimes wrote: > (Newbie alert.) > > I'm having trouble making a nested record array. I'm trying to work from > the following example on the scipy.org examples page: > > >>> mydescriptor = dtype([('x', 'f4'),('y', 'f4'), # nested recarray > ... ('nested', [('i', 'i2'),('j','i2')]

Re: [Numpy-discussion] Different numpy.int64 in 64 bit platforms?

Ivan Vilata i Balaguer wrote: > I have come across this strange behaviour of NumPy 1.0.1 under a 64 bit > AMD Opteron: > > I.e. the NumPy type used for ``long`` is not the same than for ``int`` > or explicit ``'int64'``, not even an instance. Is this a bug or is this > kind of type comparisons

Re: [Numpy-discussion] slow numpy.clip ?

David Cournapeau wrote: > On 12/22/06, Robert Kern <[EMAIL PROTECTED]> wrote: > >> Charles R Harris wrote: >> >> >>> I've been thinking about that a bit. One solution is to have a small >>> python program that takes all the pieces and writes one big build file, >>> I think something like th

Re: [Numpy-discussion] PyArray_FromDims segfault??

Xavier Gnata wrote: > Hello, > > I would like to use PyObject_CallObject to call the imshow function from > matplolib from a C code. > So, the first step is to create a 2D PyArrayObject from a C array. > > I have read the Numpy book which is great but now I'm puzzled: > My goal is to convert a C ar

Re: [Numpy-discussion] subclassing float64 (and friends)

eric jones wrote: >Hey all, > >I am playing around with sub-classing the new-fangled float64 objects >and friends. I really like the new ndarray subclassing features >(__array_finalize__, etc.), and was exploring whether or not the scalars >worked the same way. I've stubbed my toe right out o

Re: [Numpy-discussion] Scipy - Numpy incompatiblility when calling upon Old Numeric

frbeaxs wrote: > I am using Python 2.4 with Numpy 0.9.8. Matpylib graphs function > under these two version except when old numeric must be called to > utilized the spline function in contouring the graphs leading to the > error: > The version of NumPy compatible with different versions

[Numpy-discussion] Latest Array-Interface PEP

My purpose is to get feedback and criticisms from this community before display before the larger Python community. -Travis PEP: Title: Extending the buffer protocol to include the array interface Version: $Revision: $ Last-Modified: $Date: $ Author: Travis Oliphant <[EMAIL PROTECTED]

[Numpy-discussion] Latest Array-Interface PEP

My purpose is to get feedback and criticisms from this community before display before the larger Python community. -Travis PEP: Title: Extending the buffer protocol to include the array interface Version: $Revision: $ Last-Modified: $Date: $ Author: Travis Oliphant <[EMAIL PROTECTED]> St

Re: [Numpy-discussion] Latest Array-Interface PEP

Christopher Barker wrote: > Travis, > > First, thanks for doing this -- Python really needs it! > > While this approach > >> works, it requires attribute lookups which can be expensive when >> sharing many small arrays. >> > > Ah, I do like reducing that overhead -- I know I use

Re: [Numpy-discussion] Latest Array-Interface PEP

Colin J. Williams wrote: > Travis Oliphant wrote: > >> I'm attaching my latest extended buffer-protocol PEP that is trying to >> get the array interface into Python. Basically, it is a translation of >> the numpy header files into something as simple as possible

Re: [Numpy-discussion] Latest Array-Interface PEP

>> PyArrayView_FromObject(obj) >> > > yes, that's what I'm looking for -- please do add that to the C-API > > >>> By the way,, how compatible is this with the existing buffer protocol? >>> >>> >> It's basically orthogonal. In other-words, if you defined the array >> view protoc

Re: [Numpy-discussion] Latest Array-Interface PEP

Christopher Barker wrote: > eople like: > > wxPython -- Robin Dunn > PIL -- Fredrik Lundh > PyOpenGL -- Who? > PyObjC -- would it be useful there? (Ronald Oussoren) > MatplotLib (but maybe it's already married to numpy...) > PyGtk ? > It's a good start, but their is also PyMedia, PyVoxel,

Re: [Numpy-discussion] subclassing float64 (and friends)

Stefan van der Walt wrote: > On Wed, Jan 03, 2007 at 05:12:40PM -0600, eric jones wrote: > >> Thanks for the update. For now, I'll try doing what I need to by >> sub-classing float. But, I'm gonna miss __array_finalize__ :-). >> > > Looks like r3493 is intended to fix this. The 'view' m

Re: [Numpy-discussion] Latest Array-Interface PEP

Neal Becker wrote: > Travis Oliphant wrote: > > >> I'm attaching my latest extended buffer-protocol PEP that is trying to >> get the array interface into Python. Basically, it is a translation of >> the numpy header files into something as simple as possi

Re: [Numpy-discussion] Latest Array-Interface PEP

Neal Becker wrote: >Several extensions to Python utilize the buffer protocol to share >the location of a data-buffer that is really an N-dimensional >array. However, there is no standard way to exchange the >additional N-dimensional array information so that the data-buffer >i

Re: [Numpy-discussion] Latest Array-Interface PEP

Charles R Harris wrote: > > > On 1/5/07, *Stefan van der Walt* <[EMAIL PROTECTED] > > wrote: > > On Fri, Jan 05, 2007 at 09:38:49AM -0500, Neal Becker wrote: > > Several extensions to Python utilize the buffer protocol to > share > > the location

Re: [Numpy-discussion] custom accumlators

Tim Hochberg wrote: >A. M. Archibald wrote: > > >[SNIP] > > >>Really it would be nice if what vectorize() returned were effectively >>a ufunc, supporting all the various operations we might want from a >>ufunc (albeit inefficiently). This should not be difficult, but I am >>not up to writing it

Re: [Numpy-discussion] Latest Array-Interface PEP

Tim Hochberg wrote: > Christopher Barker wrote: > > [SNIP] > >> I think the PEP has far more chances of success if it's seen as a >> request from a variety of package developers, not just the numpy crowd >> (which, after all, already has numpy >> > This seems eminently sensible. Getting a

Re: [Numpy-discussion] Fwd: Advanced selection, duplicate indices, and augmented assignment

Timothy Hochberg wrote: > > > > On 1/6/07, *Robert Kern* < [EMAIL PROTECTED] > > wrote: > > Sean R. Lynch wrote: > > x = zeros((3,)) > x[array([0, 1, 1])] += array([1, 1, 1]) > x > > array([ 1., 1., 0.]) > > > > If this worked

Re: [Numpy-discussion] segfault in numpy.float64(z) for complex z

Tim Leslie wrote: >Hi All, > >While debugging a scipy crash I came across the problem outlined in > >http://projects.scipy.org/scipy/numpy/ticket/412 > >Could someone shed some light on why this is happening, I got a bit >lost in the numpy internals when I tried to track it down. > > > Recent c

Re: [Numpy-discussion] Fwd: Advanced selection, duplicate indices, and augmented assignment

Timothy Hochberg wrote: > > > On 1/6/07, *Travis Oliphant* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Timothy Hochberg wrote: > > > > > > > > On 1/6/07, *Robert Kern* < [EMAIL PROTECTED] >

Re: [Numpy-discussion] discussion about array.resize() -- compare to numarray

Sebastian Haase wrote: >On 1/8/07, Stefan van der Walt <[EMAIL PROTECTED]> wrote: > > >Hi Stéfan, > >Why is there a needed for this very confusing dualty !? >I would almost like to file a bug report on this ! > >(It definitily broke "backwards compatibility" for my code coming from >numarray ) >

Re: [Numpy-discussion] functions vs. methods

Alan G Isaac wrote: >On Mon, 8 Jan 2007, Sebastian Haase apparently wrote: > > >>Please explain again what the original decision was based >>on. >> >> > >I think the real questions are: >what do the numpy developers want in the future, >and what is the right path from here to there? > >

Re: [Numpy-discussion] Latest Array-Interface PEP

Timothy Hochberg wrote: > > > On 1/6/07, *Travis Oliphant* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Tim Hochberg wrote: > > Christopher Barker wrote: > > > > [SNIP] > > > >> I

Re: [Numpy-discussion] reduction

Charles R Harris wrote: > > > On 1/8/07, *Robert Kern* <[EMAIL PROTECTED] > > wrote: > > lorenzo bolla wrote: > > ops. I did it, too. > > should I delete it?? how?? > > I closed it as a duplicate. As a nondeveloper, you don't have the > permissions to

Re: [Numpy-discussion] reduction

Charles R Harris wrote: > > > On 1/8/07, *Robert Kern* <[EMAIL PROTECTED] > > wrote: > > lorenzo bolla wrote: > > ops. I did it, too. > > should I delete it?? how?? > > I closed it as a duplicate. As a nondeveloper, you don't have the > permissions to

Re: [Numpy-discussion] reduction

Charles R Harris wrote: > > > On 1/8/07, *Robert Kern* <[EMAIL PROTECTED] > > wrote: > > lorenzo bolla wrote: > > ops. I did it, too. > > should I delete it?? how?? > > I closed it as a duplicate. As a nondeveloper, you don't have the > permissions to

[Numpy-discussion] Docstring standards for NumPy and SciPy

There was a lively discussion on the SciPy List before Christmas regarding establishing a standard for documentation strings for NumPy / SciPy. I am very interested in establishing such a standard. A hearty thanks goes to William Stein for encouraging the discussion. I hope it is very clear

Re: [Numpy-discussion] Docstring standards for NumPy and SciPy

Christian Marquardt wrote: >Very nice! > > > >>""" >>one-line summary not using variable names or the function name >> >> > >I would personally prefer that the first name contains the function (but >nor arguments) - that way, when you are scrolling back in your terminal, >or have a version

Re: [Numpy-discussion] Latest Array-Interface PEP

Torgil Svensson wrote: > On 1/4/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >> still be used to describe a complicated block of memory to another user. >> > > Thinking of the scope "seamless data exchange between modules" my > concern with th

Re: [Numpy-discussion] Latest Array-Interface PEP

Torgil Svensson wrote: > On 1/11/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > >> On 1/11/07, Torgil Svensson <[EMAIL PROTECTED]> wrote: >> >>> Sure. I'm not objecting the memory model, what I mean is that data >>> access between modules has a wider scope than just a memory model. >>> M

Re: [Numpy-discussion] Need help for implementing a fast clip in numpy (was slow clip)

Timothy Hochberg wrote: > > > On 1/11/07, *Christopher Barker* <[EMAIL PROTECTED] > > wrote: > > [CHOP] > > > I'd still like to know if anyone knows how to efficiently loop through > all the elements of a non-contiguous array in C. > > > First, it's not that imp

Re: [Numpy-discussion] Latest Array-Interface PEP

Neal Becker wrote: > I believe we are converging, and this is pretty much the same design as I > advocated. It is similar to boost::ublas. > I'm grateful to hear that. It is nice when ideas come from several different corners. > Storage is one concept. > > Interpretation of the storage is an

Re: [Numpy-discussion] Overload binary operators with custom array type

Adam Jenkins wrote: > Timothy Hochberg ieee.org> writes: > >>You want __array_priority__; add an attribute __array_priority__ to your > > array-like object and set it's value to, say, 10 and ndarrays will defer to > your > object. > > Thank you very much. I had seen the __array_priority__ pro

Re: [Numpy-discussion] Latest Array-Interface PEP

Christopher Barker wrote: >Gael Varoquaux wrote: > > >>Yes, indeed. I was just wondering if the PEP could be used for a >>performant implementation of trees. >> >> > >That would be a whole new PEP, and one we're not the least bit ready for. > > > >>Basicaly that is mapping a tree to an >>a

Re: [Numpy-discussion] Latest Array-Interface PEP

> > I'm concerned about the direction that this PEP seems to be going. The > original proposal was borderline too complicated IMO, and now it seems > headed in the direction of more complexity. Well at least people are talking about what they would like to see. But, I think we should reign i

Re: [Numpy-discussion] Need help for implementing a fast clip in numpy (was slow clip)

Christopher Barker wrote: >>Now, it is exposed in the concept of an array iterator. Anybody >>can take advantage of it as it there is a C-API call to get an array >>iterator from the array >> >> > >Is this iterator as efficient as incrementing the index for contiguous >arrays? i.e. is ther

[Numpy-discussion] Come to PyCon if you can

Greetings, This is a little plug for coming to PyCon Feb 22-25. I am going to be there from Thursday night (Feb. 22) until Saturday evening (Feb. 25), and would like to meet with anyone interested to discuss some of the issues surrounding NumPy/SciPy and the PEPs we are working on for Python

Re: [Numpy-discussion] ownership of numpy arrays

josh kantor wrote: >I am working on a project where I am doing some interfacing with numpy >arrays at a C level. > >One thing that I want to do (using pyrex) is to call numpy functions, then >directly access the underlying double * array of the resulting ndarray and >operate on it in C/pyrex (I

Re: [Numpy-discussion] ANN: MaskedArray as a subclass of ndarray - followup

Eric Firing wrote: >Pierre GM wrote: > > >>All, >>I've updated this famous reimplementation of maskedarray I keep ranting about. >> >> >[...] > > >>I also put the file `timer_comparison.py`, that runs some unittests with each >>implementation >>(numpy.core.ma and maskedarray), and outputs

Re: [Numpy-discussion] ANN: MaskedArray as a subclass of ndarray -?followup

Matt Knox wrote: >>Moving the implementation to the C-level also has its downside. To >>me, at least, Python code is much more readable and hence easier to >>maintain. >> >>Is there a way that we can implement only the speed-critical methods >>in C? >> >>Cheers >>Stéfan >> >> >> > >Implementi

Re: [Numpy-discussion] how to recognize a numpy-scalar type at the C level and how to convert

Sebastian Haase wrote: >Hi again, >I finally bought the numpy-book. >Browsing through the 370 pages I found this: >PyArray IsScalar (op, cls) >Evaluates true if op is an instance of PyArrType Type. > >Is this what I need to check for a given scalar type. > > Yes. Remember that cls can be a "Ge

Re: [Numpy-discussion] concatenate a tuple of lists 10x slower in numpy 1.0.1

Martin Spacek wrote: > Hello, > > I just upgraded from numpy 1.0b5 to 1.0.1, and I noticed that a part of > my code that was using concatenate() was suddenly far slower. I > downgraded to 1.0, and the slowdown disappeared. Here's the code > and the profiler results for 1.0 and 1.0.1: > I have n

Re: [Numpy-discussion] C-API: datatype for arrays of indices

Martin Wiechert wrote: >Hi list, > >does anybody know, what datatype arrays C-API functions like > >PyArray_SearchSorted >PyArray_ArgSort > >return? Can I rely on them being npy_intp? > > > Yes. -Travis ___ Numpy-discussion mailing list Numpy-discus

Re: [Numpy-discussion] Unable to build numpy in cygwin

Crider, Joseph A wrote: >I am still clueless as to why numpy.numarray will not build for numpy >1.0 and later. As I am currently not using much from either numpy or >scipy, but do want to be able to use some of the 1.0 features >(especially the order keyword for sort on record arrays), I've decid

[Numpy-discussion] PyGame Port

I just finished porting PyGame to use NumPy. It seemed to work fine. I ran only a few demos though, and so haven't fleshed out all the details. Please encourage library-writers to use NumPy when possible. -Travis Index: src/surfarray.c =

Re: [Numpy-discussion] C-API: deallocating a partially filled object array

Martin Wiechert wrote: >On Friday 26 January 2007 21:03, Robert Kern wrote: > > >>Martin Wiechert wrote: >> >> >>>Hi gurus, >>> >>>is it (in C) safe to deallocate an array of type NPY_OBJECT, which >>>carries NULL pointers? >>> >>> >>Possibly, I'm not sure without doing some more code-

Re: [Numpy-discussion] Arrays of poly1d objects, is this a bug?

Fernando Perez wrote: >Hi all, > >I'm puzzled by this behavior a colleague ran into: > >In [38]: p1=N.poly1d([1.]) > >In [39]: a=N.array([p1],dtype='O') > >In [40]: a >Out[40]: array([], shape=(1, 0), dtype=object) > >In [42]: print a >[] > > > Stefan correctly identified the problem. The dim

Re: [Numpy-discussion] inplace operations

BBands wrote: >If I have a NumPy array like so: > >[[1, 12], > [2, 13], > [3, 14], > [4, 15], > [5, 16], > [6, 15], > [7, 14]] > >How can I do an inplace diff, ending up with this? > >[[1, 0], > [2, 1], > [3, 1], > [4, 1], > [5, 1], > [6, -1], > [7, -1]] > > Probably can be done (but it's a bit

Re: [Numpy-discussion] Pickling ufuncs?

James A. Bednar wrote: >Hi, > >Does anyone know whether it is possible to pickle and unpickle numpy >ufuncs? > Not directly. Ufuncs are a built-in type and do not have the required __reduce__ method needed to be pickleable. It could be added, but hasn't been. > I can't find anything about

[Numpy-discussion] Cutting 1.0.2 release

I think it's time for the 1.0.2 release of NumPy. What outstanding issues need to be resolved before we do it? Hopefully, we can do it by the end of the week. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scip

Re: [Numpy-discussion] Pickling ufuncs?

Robert Kern wrote: > Note that this is a hack. It won't work for the ufuncs in scipy.special, for > example. > > We should look into including __module__ information in ufuncs. This is how > regular functions are pickled. > > This sounds like a good idea. Would it be possible to add a "dict" o

[Numpy-discussion] Patch for RPy to use NumPy uploaded to www.scipy.org

I've added a patch to the Porting to NumPy page so that RPy uses NumPy instead of Numeric. It would be very helpful for unification if these package authors would accept these patches. NumPy is far enough along in development that I don't think there is any reason for new releases of package

[Numpy-discussion] Requests for NumPy Ports?

I'm trying to help out the conversion to NumPy by offering patches to various third-party packages that have used Numeric in the past. Does anybody here have requests for which packages they would like to see converted to use NumPy? Ultimately, we are at the mercy of the package-owners to com

Re: [Numpy-discussion] memmap close() and flush()

Sebastian Haase wrote: > Hi! > Do numpy memmap have a way of explicitly > flushing data to disk > and/or > closing the memmap. > There is a sync method that performs the flush. To close the memmap, delete it. More detail: The memmap sub-class has a _mmap attribute that is the Python mem

Re: [Numpy-discussion] Requests for NumPy Ports?

Keith Goodman wrote: >On 1/30/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > >>I'm trying to help out the conversion to NumPy by offering patches to >>various third-party packages that have used Numeric in the past. >> >>Does anybody here have re

Re: [Numpy-discussion] Requests for NumPy Ports?

Christopher Barker wrote: >Travis Oliphant wrote: > > >>Most of these are probably the gtk-python extension which can use >>Numeric >> >> > >This strikes me as an excellent argument for including an n-d array in >the Python standard lib. > &g

Re: [Numpy-discussion] memmap close() and flush()

Fernando Perez wrote: >On 1/31/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > >>Sebastian Haase wrote: >> >> >>>Hi! >>>Do numpy memmap have a way of explicitly >>>flushing data to disk >>>and/or >>>closing

Re: [Numpy-discussion] array copy-to-self and views

Zachary Pincus wrote: >Hello folks, > >I recently was trying to write code to modify an array in-place (so >as not to invalidate any references to that array) via the standard >python idiom for lists, e.g.: > >a[:] = numpy.flipud(a) > >Now, flipud returns a view on 'a', so assigning that to 'a

Re: [Numpy-discussion] large memory address space on Mac OS X (intel)

Louis Wicker wrote: > Dear list: > > I cannot seem to figure how to create arrays > 2 GB on a Mac Pro > (using Intel chip and Tiger, 4.8). I have hand compiled both Python > 2.5 and numpy 1.0.1, and cannot make arrays bigger than 2 GB. I also > run out of space if I try and 3-6 several arrays

Re: [Numpy-discussion] large memory address space on Mac OS X (intel)

Louis Wicker wrote: > Travis: > > yes it does. Its the Woodcrest server chip > > which > supports 32 and 64 bit operations. For example the new Intel Fortran > compiler can grab more than 2 GB of memory (its a

Re: [Numpy-discussion] array copy-to-self and views

Zachary Pincus wrote: >>>A question, then: Does this represent a bug? Or perhaps there is a >>>better idiom for modifying an array in-place than 'a[:] = ...'? Or is >>>incumbent on the user to ensure that any time an array is directly >>>modified, that the modifying array is not a view of the orig

Re: [Numpy-discussion] array copy-to-self and views

Christopher Barker wrote: >Zachary Pincus wrote: > > >>Say a function that (despite Tim's pretty >>reasonable 'don't do that' warning) will return true when two arrays >>have overlapping memory? >> >> > >I think it would be useful, even if it's not robust. I'd still like to >know if a g

[Numpy-discussion] classmethods for ndarray

What is the attitude of this group about the ndarray growing some class methods? I'm thinking that we should have several. For example all the fromXXX functions should probably be classmethods ndarray.frombuffer ndarray.fromfile etc. -Travis ___

Re: [Numpy-discussion] classmethods for ndarray

Sebastian Haase wrote: >Travis, >Could you explain what a possible downside of this would be !? >It seems that if you don't need to refer to a specific "self" object >that a class-method is what it should - is this not always right !? > > > I don't understand the last point. Classmethods would

Re: [Numpy-discussion] classmethods for ndarray

Christopher Barker wrote: >Travis Oliphant wrote: > > >>I'm thinking that we should have several. For example all the fromXXX >>functions should probably be classmethods >> >>ndarray.frombuffer >>ndarray.fromfile >> >> > >

[Numpy-discussion] New may_share_memory function

In SVN there is a new function may_share_memory(a,b) which will return True if the memory foot-print of the two arrays over-lap. >>> may_share_memory(a, flipud(a)) True This is based on another utility function byte_bounds that returns the byte-boundaries of any object exporting the Python s

Re: [Numpy-discussion] Native byteorder representation

Francesc Altet wrote: >Hi, > >We have been bitten by a small glitch related with the representation of >native byteorders. Here is an example exposing the problem: > > > numpy.dtype('>>> >'=' > > numpy.dtype('>i4').newbyteorder('little').byteorder >'<' >

Re: [Numpy-discussion] bug in numpy.equal?

Tom Denniston wrote: >The behavior below seems strange to me. The string array is type S3 >yet it says that comparison with 'abc' is not implemented. The == >operator seems to work though. Is there a subtlty I am missing or is >it simply a bug? > > > No bug. Ufuncs do not work with variable

Re: [Numpy-discussion] Please help with subclassing numpy.ndarray

Sturla Molden wrote: >>def __new__(cls,...) >> ... >>(H, edges) = numpy.histogramdd(..) >>cls.__defaultedges = edges >> >>def __array_finalize__(self, obj): >>if not hasattr(self, 'edges'): >>self.edges = self.__defaultedges >> >> > >So in order to get an instance attr

Re: [Numpy-discussion] Bug in numpy user-define types mechanism causes segfault on multiple calls to a ufunc

Tom Denniston wrote: >I am trying to register a custom type to numpy. When I do so it works >and the ufuncs work but then when I invoke any ufunc twice the second >time my python interpretter segfaults. I think i know what the >problem is. In the select_types method in ufuncobject.c in >numpy/c

Re: [Numpy-discussion] Please help with subclassing numpy.ndarray

Reggie Dugard wrote: >On Wed, 2007-02-07 at 14:36 -0700, Travis Oliphant wrote: > > >>Sturla Molden wrote: >> >> >> >>>>def __new__(cls,...) >>>>... >>>> (H, edges) = numpy.histogramdd(..) >>>> cls.

  1   2   3   4   5   6   7   8   >