Re: [Numpy-discussion] numpy.ctypeslib.ndpointer and the restype attribute [patch]

Thomas Heller wrote: > Thomas Heller schrieb: > >>> Sturla Molden schrieb: >>> On 3/26/2009 12:41 PM, Jens Rantil wrote: > Wouldn't my code, or a tweak of it, be a nice feature in > numpy.ctypeslib? Is this the wrong channel for proposing things like >

[Numpy-discussion] DVCS at PyCon

FYI from PyCon Here at PyCon, it has been said that Python will be moving towards DVCS and will be using bzr or mecurial, but explicitly *not* git. It would seem that *git* got the "lowest" score in the Developer survey that Brett Cannon did. The reasons seem to be: * git doesn't have g

Re: [Numpy-discussion] is it a bug?

Robert Kern wrote: > On Thu, Mar 12, 2009 at 01:34, Stéfan van der Walt wrote: > >> 2009/3/12 Robert Kern : >> idx = np.array([0,1]) e = x[0,:,idx] print e.shape #-> return (2,3). I think the right answer should be (3,2). Is # it a bug here? my numpy

Re: [Numpy-discussion] is it a bug?

shuwj5...@163.com wrote: >> >> It's certainly weird, but it's working as designed. Fancy indexing via >> arrays is a separate subsystem from indexing via slices. Basically, >> fancy indexing decides the outermost shape of the result (e.g. the >> leftmost items in the shape tuple). If there are any

Re: [Numpy-discussion] suggestion for generalizing numpy functions

Darren Dale wrote: > On Mon, Mar 9, 2009 at 9:50 AM, Darren Dale > wrote: > > I spent some time over the weekend fixing a few bugs in numpy that > were exposed when attempting to use ufuncs with ndarray > subclasses. It got me thinking that, with relatively l

[Numpy-discussion] NumPy SVN?

Is commit to NumPy SVN still turned off? How do I get a working SVN again? -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 64-bit numpy questions?

Todd Miller wrote: > Hi, > > I've been looking at a 64-bit numpy problem we were having on Solaris: > > >>> a=numpy.zeros(0x18000,dtype='b1') > >>> a.data > Traceback (most recent call last): > File "", line 1, in > ValueError: size must be zero or positive > > A working fix seemed to be thi

Re: [Numpy-discussion] Creating arrays with 'titles' in dtype causes TypeError on data access

Ralph Heinkel wrote: > However here something is strange: > > arr = array([('john', 4),('mark', 3)], > dtype=[(('source:yy', 'name'),'O'),(('source:xx','id'),int)]) > arr[0] > ('john', 4) > arr[0][0] > Traceback (most recent cal

Re: [Numpy-discussion] views and object lifetime

Neal Becker wrote: > How is it ensured, at the C api level, that when I have an array A, and a view > of it B, that the data is not destroyed until both A and B are? > One array, A, owns the data and will deallocate it only when its reference-count goes to 0.The view, B, has a reference to

Re: [Numpy-discussion] FYI: New "select-multiple-fields" behavior

Stéfan van der Walt wrote: > Hi Travis > > 2009/2/12 Travis E. Oliphant : > >> ary['field1', 'field3'] raises an error >> ary[['field1', 'field3']] is the correct spelling and returns a copy of >> the data in those fields i

[Numpy-discussion] FYI: New "select-multiple-fields" behavior

Hi all, As of r6358, I checked in the functionality to allow selection by multiple fields along with a couple of tests. ary['field1', 'field3'] raises an error ary[['field1', 'field3']] is the correct spelling and returns a copy of the data in those fields in a new array. -Travis _

Re: [Numpy-discussion] Selection of only a certain number of fields

Francesc Alted wrote: > A Saturday 07 February 2009, Neil escrigué: > >> Travis E. Oliphant enthought.com> writes: >> >>> I've been fairly quiet on this list for awhile due to work and >>> family schedule, but I think about how things can impro

[Numpy-discussion] Selection of only a certain number of fields

Hi all, I've been fairly quiet on this list for awhile due to work and family schedule, but I think about how things can improve regularly.One feature that's been requested by a few people is the ability to select multiple fields from a structured array. Thus, suppose *arr* is a structur

Re: [Numpy-discussion] numpy and bitwise arrays?

Muhammad Alkarouri wrote: > --- On Wed, 21/1/09, Stéfan van der Walt wrote: > > >> From: Stéfan van der Walt >> > ... > >> You can also take a look at Ilan Schnell's bitarray: >> >> http://pypi.python.org/pypi/bitarray/ >> > > Looks good to me. Thanks for the suggestion. > You

Re: [Numpy-discussion] Trying to implement the array interface

Mark Asbach wrote: > Hi there, > > I'm currently extending the Python wrapper for the Open Computer > Vision Library (opencv) with the goal to interface numerical libraries > as seemless as possible. Unfortunately, it doesn't seem to be that > easy ;-) > > What I've done so far: > > - Added an _

Re: [Numpy-discussion] memmap & dtype issue

Wim Bakker wrote: > For a long time now, numpy's memmap has me puzzled by its behavior. When I use > memmap straightforward on a file it seems to work fine, but whenever I try to > do a memmap using a dtype it seems to gobble up the whole file into memory. > I don't understand your question.

Re: [Numpy-discussion] Ironclad v0.7 released (NumPy on IronPython)

William Reade wrote: > Hi all > > Hopefully someone here will be interested in this, and it won't be > considered too spammy... please let me know if this isn't welcome, and > I'll desist in future. > I welcome these announcements, so my opinion is that you continue. Thanks for the work. It

[Numpy-discussion] ANNOUNCE: EPD with Py2.5 version 4.0.30002 RC2 available for testing

Hello, We've recently posted the beta1 build of EPD (the Enthought Python Distribution) with Python 2.5 version 4.1.30001 to the EPD website. You may download the beta from here: http://www.enthought.com/products/epdearlyaccess.php You can check out the release notes here: https:

Re: [Numpy-discussion] More loadtxt() changes

Pierre GM wrote: > OK then, I'll take care of that over the next few weeks... > > Thanks Pierre. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] More loadtxt() changes

John Hunter wrote: > On Tue, Nov 25, 2008 at 12:16 PM, Pierre GM <[EMAIL PROTECTED]> wrote: > > >> A la mlab.csv2rec ? It could work with a bit more tweaking, basically >> following John Hunter's et al. path. What happens when the column names are >> unknown (read from the header) or wrong ? >>

Re: [Numpy-discussion] Proposal for changing the names of inverse trigonometrical/hyperbolic functions

Francesc Alted wrote: > So, IMHO, I think it would be better to rename the inverse trigonometric > functions from ``arc*`` to ``a*`` prefix. Of course, in order to do > that correctly, one should add the new names and add a > ``DeprecationWarning`` informing that people should start to use the

Re: [Numpy-discussion] Old-style classes in tests

Tom Wright wrote: > I am currently working on the Ironclad project porting numpy to Ironpython. > > It would be quite useful for me if HermitianTestCase in test_linalg.py > was a new style-class instead of an old-style class - since Ironpython > has a bug where dir operations do not work for clas

Re: [Numpy-discussion] PIL.Image.fromarray bug in numpy interface

Jim Vickroy wrote: > Hello, > > While using the PIL interface to numpy, I rediscovered a logic error > in the PIL.Image.fromarray() procedure. The problem (and a solution) > was mentioned earlier at: > > * > http://projects.scipy.org/pipermail/numpy-discussion/2006-December/024903.html > >

Re: [Numpy-discussion] Breaking up the umathmodule file.

Charles R Harris wrote: > Hi All, > > > > I propose: > > umath_funcs_c99.inc.src > umath_funcs.inc.src > umath_loops.inc.src > umath_object.inc > umathmodule.c This sounds fine to me. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org

Re: [Numpy-discussion] New ufuncs

Charles R Harris wrote: > > > On Sun, Nov 9, 2008 at 11:29 PM, T J <[EMAIL PROTECTED] > > wrote: > > On Thu, Nov 6, 2008 at 3:01 PM, T J <[EMAIL PROTECTED] > > wrote: > > On Thu, Nov 6, 2008 at 2:36 PM, Charles R Harris > > <[EMAI

Re: [Numpy-discussion] numpy array serialization with JSON

Christopher Barker wrote: > Matthieu Brucher wrote: > >> Last time I checked, repr() does the same thing as str(): the middle >> of the array may not be displayed... >> > > right. darn -- is that controllable? > numpy.set_printoptions(threshold=1000) -Travis __

Re: [Numpy-discussion] Adding the ability to "clone" a few fields from a data-type

> I'm not sure what this accomplishes. Would the dummy fields that fill > in the space be inaccessible? E.g. tuple(subarr[i,j,k]) gives a tuple > with no numpy.void scalars? That would be a novel feature, but I'm not > sure it fits the problem. On the contrary: > Yes, that was the idea. You

[Numpy-discussion] Adding the ability to "clone" a few fields from a data-type

Hi all, I'd like to add to NumPy the ability to clone a data-type object so that only a view fields are copied over but that it retains the same total size. This would allow, for example, the ability to "select out a few records" from a structured array using subarr = arr.view(cloned_dtype)

Re: [Numpy-discussion] creating a Numeric array from a numpy array LEAKS memory

Jose Borreguero wrote: > Dear numpy users, > > I need to pass a Numeric array to some oldie code from a numpy array. > I decided to go like this: > > for i in range(BIGNUMER): > my_numpy_array=grabArray(i) > na=Numeric.array( my_numpy_array, Numeric.Float) > oldie_code(na) > > The cons

Re: [Numpy-discussion] numpy CAPI questions

Lane Brooks wrote: > I am using the numpy CAPI to write an extension module that returns a > numpy Array from an imaging data source. I collect the image into a > buffer that I allocate. I then create numpy Array using the > PyArray_New(..) function and pass it the buffer. I then set the > NP

Re: [Numpy-discussion] choose() broadcasting

Roman Bertle wrote: > * Travis E. Oliphant <[EMAIL PROTECTED]> [081003 22:20]: > >> Roman Bertle wrote: >> >>> Hello, >>> >>> I have found something I call a bug in the numpy choose() method and >>> wanted to report it in trac. &g

Re: [Numpy-discussion] LU factorization?

Charles R Harris wrote: > > > I would just add the bits that are already there and don't add any > extra dependencies, i.e., they are there when numpy is built without > ATLAS or other external packages. The determinant function in linalg > uses the LU decomposition, so I don't see why that shou

Re: [Numpy-discussion] var bias reason?

Gabriel Gellner wrote: > Some colleagues noticed that var uses biased formula's by default in numpy, > searching for the reason only brought up: > > http://article.gmane.org/gmane.comp.python.numeric.general/12438/match=var+bias > > which I totally agree with, but there was no response? Any reason

Re: [Numpy-discussion] Priority rules between numpy scalars and 0d arrays

Pierre GM wrote: > All, > Sorry to bring back this subject, but I still haven't got any proper answers: > > * What are the priority rules between numpy scalars and 0d arrays ? > There aren't really any specified. However, there is behavior that emerges from what is specified. The problem is t

Re: [Numpy-discussion] dtype behavior

ctw wrote: > Hi -- Can somebody here explain the following behavior: > > In [1]: tst = np.array([5.]) > > In [2]: tst > Out[2]: array([ 5.]) > > In [3]: tst.shape > Out[3]: (1,) > > In [4]: tst.dtype > Out[4]: dtype('float64') > > In [5]: tst.dtype = np.int > > In [6]: tst > Out[6]: array([

Re: [Numpy-discussion] Merged clean_math_config branch

David Cournapeau wrote: > Hi there, > > Just to mention that I merged back my changes from the > clean_math_config branch into trunk. The main point of the branch is to > clean our math configuration. If this causes problems, please report it. > I built and tested on mac os x, linux 32 bits an

Re: [Numpy-discussion] PyArray_New bug?

Ravi wrote: > Hi, > PyArray_New seems to return a fortran contiguous array regardless of the > requested array type. I am using numpy version 1.1.1. > > PyObject *obj = PyArray_New( &PyArray_Type, 2, dims, /*whatever*/, NULL, > NULL, 0, NPY_CARRAY, NULL ); > PyOb

Re: [Numpy-discussion] choose() broadcasting, and Trac

Roman Bertle wrote: > Hello, > > I have found something I call a bug in the numpy choose() method and > wanted to report it in trac. > Thanks for your report. I'm not sure why you are having trouble with Trac, but I've created a ticket for this problem. -Travis __

Re: [Numpy-discussion] will array(Python set) be ever implemented as cast method?

dmitrey wrote: > hi all, > will array(Python set) (and asarray, asfarray etc) ever be implemented > as cast method? > Use fromiter instead.We could special case set objects in array(...) if that is deemed desirable. -Travis ___ Numpy-discuss

Re: [Numpy-discussion] why type(array(1).tolist()) is int?

dmitrey wrote: > let me also note that list(array((1))) returns > > Traceback (innermost last): > File "", line 1, in > TypeError: iteration over a 0-d array > > D. > This is expected. 0-d arrays are currently not iterable. -Travis ___ Numpy-disc

Re: [Numpy-discussion] PyArray_Resize reference counting

Ravi wrote: > On Tuesday 30 September 2008 16:26:08 Travis E. Oliphant wrote: > >> You need to do something like: >> >> temp = PyArray_Resize(array,...) >> Py_DECREF(array) >> array = temp >> > > In this case, since a new array may be return

Re: [Numpy-discussion] Help needed with the priority of 0d-arrays and np.scalars

Pierre GM wrote: > Sorry to bump my own post, I know it's rude... > > However, I'm in dire need for some pointers: what are the priority rules when > multiplying numpy scalars and 0d ndarrays ? > > Thanks a lot in advance > ___ > Numpy-discussion mailin

Re: [Numpy-discussion] PyArray_Resize reference counting

Ravi wrote: > Hi, > Consider the following code: > >PyArrayObject *array = get_me_an_array_along_with_a_reference(); /* 1 */ >PyArray_Dims *dims = get_me_some_dims(); /* 2 */ >array = (PyArrayObject *)PyArray_Resize( array, dims, 1 ); /* 3 */ > > Is the code above valid? No. You nee

Re: [Numpy-discussion] Are there command similar as Matlab find command?

frank wang wrote: > Hi, > > I am trying to find a command in numpy or python that perform similar > function as Matlab find command. It will return the indexes of array > that satisfy a condition. So far I have not found anything. There are several ways to do this, but what are you trying to d

Re: [Numpy-discussion] Bug fix or behavior change?

Charles R Harris wrote: > Hi All, > > Currently subtract for boolean arrays is defined in > > /**begin repeat > * Arithmetic operators > * > * # OP = ||, ^, &&# > * #kind = add, subtract, multiply# > */ > static void > [EMAIL PROTECTED]@(char **args, intp *dimensions, intp *steps, void *func)

Re: [Numpy-discussion] Suggestion for recarray.view

Pierre GM wrote: > All, > I'd like to submit the following suggestion for recarray.view, so that it > could accept two keywords like standard ndarrays do. > As a change in records.py can potentially affect a lot of people (probably > more than a change in numpy.ma), I'm not confident enough to c

Re: [Numpy-discussion] patch for new mgrid / ogrid functionality

Stéfan van der Walt wrote: > 2008/9/13 Travis E. Oliphant <[EMAIL PROTECTED]>: > >> Generally, it is O.K. except that he changes the output from a numpy >> array to a list of numpy arrays. This is a small change, but it is an >> API change. I'm not sure w

Re: [Numpy-discussion] patch for new mgrid / ogrid functionality

Stéfan van der Walt wrote: > Hey all, > > David Kaplan implemented a generalised ogrid/mgrid, and would like to > have some feedback. See > > http://projects.scipy.org/pipermail/numpy-discussion/2008-August/036691.html > > for his original email and attachment. > > If no one objects to such functi

Re: [Numpy-discussion] Numpy array flags - BUG?

Thomas Hrabe wrote: > Hello everyone, > > I must report odd behaviour of the numpy arrays regarding the flags set for > each array object in C++. > Please have a look at the following code: > > static PyObject* test(PyObject* self,PyObject* args){ > > int s[2]; > s[0] = 1; >

Re: [Numpy-discussion] Dealing with types in extension modules

Lane Brooks wrote: > Travis E. Oliphant wrote: >> Lane Brooks wrote: >> >>> When writing an numpy extension module, what is the preferred way to >>> deal with the all the possible types an ndarray can have? >>> >>> I have some data processing

Re: [Numpy-discussion] Dealing with types in extension modules

Lane Brooks wrote: > When writing an numpy extension module, what is the preferred way to > deal with the all the possible types an ndarray can have? > > I have some data processing functions I need to implement and they need > to be generic and work for all the possible numerical dtypes. I do n

Re: [Numpy-discussion] Issue w/ ndarray.view

Pierre GM wrote: > All, > I was fixing MaskedArray.view for masked arrays with flexible type when I ran > into a small pb with view. > The new definition accepts 2 keywords dtype and type. I thought I could > easily > redefined MaskedArray.view as > > def view(self, dtype=None, type=None): >

[Numpy-discussion] NumPy arrays that use memory allocated from other libraries or tools

I wanted to point anybody interested to a blog post that describes a useful pattern for having a NumPy array that points to the memory created by a different memory manager than the standard one used by NumPy. The pattern shows how to create a NumPy array that points to previously allocated

Re: [Numpy-discussion] Getting a numpy array from a ctype pointer

Paulo J. S. Silva wrote: > After some trial and erros, I found a solution, described below. Is this > the best one? Looks a little convoluted to me (C represents ctypes > module and np numpy): > > Array = n*C.c_double > x = Array.from_address(C.addressof(x.contents)) > x = n

Re: [Numpy-discussion] Getting a numpy array from a ctype pointer

Paulo J. S. Silva wrote: > Hello, > > I am writing some code interfacing C and Python using ctypes. In a > callback function (in Python) I get in a parameter x which is c_double > pointer and a parameter n which is c_int representing the length of the > array. > > How can I transform this informat

Re: [Numpy-discussion] BUG in numpy.loadtxt?

Ryan May wrote: > Stefan (or anyone else who can comment), > > It appears that the usecols argument to loadtxt no longer accepts numpy > arrays: > Could you enter a ticket so we don't lose track of this. I don't remember anything being intentional. -Travis _

Re: [Numpy-discussion] numpy 1.3: cleaning the math configuration, toward a warning free build

> Should I write a nep for that too ? Or a patch is enough ? > > I think a patch with a useful explanation of the patch in the ticket is sufficient. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mai

Re: [Numpy-discussion] rc1 update

Andrew Straw wrote: > Joining the party late, here, so I don't know how much has already been > said... Particularly in favor of renaming NPY_VERSION. What's the benefit? > > I'm -1 on removing the name NPY_VERSION. It would cause unnecessary > breakage. > > I'm -0 on defining an additional NPY_ABI

Re: [Numpy-discussion] [SciPy08] Documentation BoF

Pauli Virtanen wrote: > > - I vaguely remember someone mentioned having done numpybook -> RST > conversion. If so, is the result somewhere available? > Was something done towards this in the Scipy'08 sprints? > > Yes, Gabriel Gellner made progress on this during the sprints, and I asked hi

[Numpy-discussion] Report from SciPy

Hi everybody, Robert K, Chuck H, Stefan VdW, Jarrod M, David C, and I had a nice discussion about the future directions of NumPy. We resolved some things and would like community feedback on them if there are opinions. * we will be moving to time-based releases (at least 2 times a year -- N

[Numpy-discussion] How to replace a loop for a ufunc (to test optimizations)

Yesterday at the SciPy conference I suggested it would be a good idea to add a function to replace one of the inner loops in a ufunc so that an extension module could test an optimized inner loop more easily. It turns out that this is such a good idea that it's actually already in the code.

Re: [Numpy-discussion] numpy.core.numerictypes questions

William Reade wrote: > Hi > > I hope this is the right place for this question... if not, I apologise, > and ask only that you please direct me somewhere more appropriate. > > Line 532 of numerictypes.py reads "_unicodesize = > array('u','U1').itemsize", but _unicodesize itself does not appear to

Re: [Numpy-discussion] NumPy 1.2.0b2 released

Stéfan van der Walt wrote: > 2008/8/18 Travis E. Oliphant <[EMAIL PROTECTED]>: > >> I say go ahead including changing #1 and #4. Let's leave 5 for the moment. >> > > I ran several benchmarks and made sure that these imports take a > minimal amount of

Re: [Numpy-discussion] NumPy 1.2.0b2 released

Andrew Dalke wrote: > Andrew Dalke: > >> Any chance of someone reviewing my suggestions for >> making the import somewhat faster still? >> >>http://scipy.org/scipy/numpy/ticket/874 >> >> > > > Travis E. Oliphant: > >> In su

Re: [Numpy-discussion] C-API change for 1.2

Charles R Harris wrote: > > > On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau <[EMAIL PROTECTED] > > wrote: > > On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau > <[EMAIL PROTECTED] > wrote: > > On Sat, Aug 16, 2008 at 11:16 PM,

Re: [Numpy-discussion] C-API change for 1.2

David Cournapeau wrote: > On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > >> On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris >> <[EMAIL PROTECTED]> wrote: >> >>> I'm slowly coming to the conviction that there should be no C-ABI changes in >>> 1.2. >>>

Re: [Numpy-discussion] Generalized ufuncs?

> The good news is that the patch just uses of the existing code to deal with > all the tricky issues (this is why the patch is so short). By the way, sort > could be implemented with the proposed specifications, its signature would be > "(i)->(i)". I agree that it would be nice if that code

Re: [Numpy-discussion] long double woes on win32

Charles R Harris wrote: > > > Yes. I don't think MS will support "true" long doubles any time soon > and this affects printing and the math functions. I'm not sure what > the best solution is, there are various possibilities. > > 1) We could define the numpy longdouble type to be double, which ma

Re: [Numpy-discussion] C-API change for 1.2

Jon Wright wrote: > Travis, Stéfan, > > I missed Travis mail previously. Are you *really* sure you want force > all C code which uses numpy arrays to be recompiled? Re-compilation is necessary at some point. We have not required recompilation for a long time now.Yes, it is a pain for distr

Re: [Numpy-discussion] NumPy 1.2.0b2 released

Andrew Dalke wrote: > > Can that be made quicker? Not easily. "lib" is > first imported in "add_newdocs". Personally, I > want to get rid of add_newdocs and move the > docstrings into the correct locations. > Where would that be, in the C-code? The reason for add_newdocs is to avoid writing

Re: [Numpy-discussion] Addition of a dict object to all NumPy objects

Robert Kern wrote: > 3) Are the additional 4-8 bytes too expensive >>> One of the problems with numarray was the time taken to allocate small >>> arrays. Would adding a dictionary slow down the allocation of numpy arrays? >>> No, I don't think so, not if we did nothing by

[Numpy-discussion] Addition of a dict object to all NumPy objects

Hello all, While we are on the subject of C-API changes, I've noticed that quite a few of the sub-classes of ndarray are constructed to basically add meta-information to the array. What if the base-class ndarray grew a dict object at it's end to hold meta information. Naturally, several

Re: [Numpy-discussion] NumPy 1.2.0b2 released

Andrew Dalke wrote: > I forgot to mention.. > > > On Aug 15, 2008, at 9:00 AM, Travis E. Oliphant wrote: > >> 1) Removing ctypeslib import >> >> * Can break code if somebody has been doing import numpy and then >> using >> numpy.ctypesli

Re: [Numpy-discussion] NumPy 1.2.0b2 released

Andrew Dalke wrote: > On Aug 14, 2008, at 11:07 PM, Alan G Isaac wrote: > >> Btw, numpy loads noticeably faster. >> > > > Any chance of someone reviewing my suggestions for > making the import somewhat faster still? > >http://scipy.org/scipy/numpy/ticket/874 > > So, what is the attit

Re: [Numpy-discussion] Generalized ufuncs?

Travis E. Oliphant wrote: >> Can we fix the ticket notification mailings some day? It's been almost >> four months now. >> > That would be fabulous. So far nobody has figured out how... Jarrod?? > >> Re: the patch. I noticed the replacement of the

Re: [Numpy-discussion] Generalized ufuncs?

> > Can we fix the ticket notification mailings some day? It's been almost > four months now. That would be fabulous. So far nobody has figured out how... Jarrod?? > > Re: the patch. I noticed the replacement of the signed type int by an > unsigned size_t. Where did you notice this? I didn't

Re: [Numpy-discussion] Generalized ufuncs?

> > Numpy 1.2 is for documentation, bug fixes, and getting the new testing > framework in place. Discipline is called for if we are going to have > timely releases. We also agreed to a change in the C-API (or at least did not object too loudly). I'm in favor of minimizing that sort of change.

Re: [Numpy-discussion] min() of array containing NaN

Thomas J. Duck wrote: > Determining the minimum value of an array that contains NaN produces > a surprising result: > > >>> x = numpy.array([0,1,2,numpy.nan,4,5,6]) > >>> x.min() > 4.0 > > I expected 0.0. Is this the intended behaviour or a bug? I am using > numpy 1.1.1. > NAN's don't pl

Re: [Numpy-discussion] are fortran extensions numpy version dependent?

mark wrote: > Hello list - > > Easy question: do fortran extension created with numpy 1.0.4 also work > with numpy 1.1.1? And vice versa? > Yes. 1.2 will have a small change requiring a new build (and maybe a change to your code if you used the details of PyArray_Descr). -Travis __

[Numpy-discussion] C-API change for 1.2

Hi all, The 1.2 version of NumPy is going to be tagged. There is at least one change I'd like to add: The hasobject member of the PyArray_Descr structure should be renamed to "flags" and converted to a 32-bit integer. What does everybody think about this change? It should have minimal

Re: [Numpy-discussion] Appending data to a big ndarray

oc-spam66 wrote: > Hello, > > I would like to build a big ndarray by adding rows progressively. > > I considered the following functions : append, concatenate, vstack and > the like. > It appears to me that they all create a new array (which requires > twice the memory). > > Is there a method for

Re: [Numpy-discussion] Cython/NumPy syntax

Gael Varoquaux wrote: > On Wed, Aug 06, 2008 at 10:35:06AM +0200, Dag Sverre Seljebotn wrote: > >> Stéfan van der Walt wrote: >> >>> 2008/8/6 Dag Sverre Seljebotn <[EMAIL PROTECTED]>: >>> - Require an ndim keyword: > > cdef numpy.ndarray[numpy.int64, ndim=2

Re: [Numpy-discussion] Bilateral filter

Nadav Horesh wrote: > Attached here my cython implementation of the bilateral filter, which > is my first cython program. I would ask for the following: > >1. Is there any way to speed up the code just by "cosmetic" > modifications? >2. In particular I use the unportable gcc function

Re: [Numpy-discussion] Error creating an array

Sameer DCosta wrote: > On Tue, Aug 5, 2008 at 2:35 PM, Travis E. Oliphant > <[EMAIL PROTECTED]> wrote: > > >> You must uses tuples for the individual "records" when constructing >> arrays with the "array" command. >> > >

Re: [Numpy-discussion] Error creating an array

Sameer DCosta wrote: > Im having a little trouble creating a numpy array with a specific > dtype. I can create the array b with dtype=int, but not with the dtype > I want. Any idea what I am doing wrong here? > You must uses tuples for the individual "records" when constructing arrays with the

Re: [Numpy-discussion] No Copy Reduce Operations

Luis Pedro Coelho wrote: > Hello all, > > Numpy arrays come with several reduce operations: sum(), std(), argmin(), > min(), > > The traditional implementation of these suffers from two big problems: It is > slow and it often allocates intermediate memory. I have code that is failing > with

Re: [Numpy-discussion] import numpy fails with multiarray.so: undefined symbol: PyUnicodeUCS2_FromUnicode

G wrote: > Hello, > I have installed the svn version of numpy. I have deleted all previous > versions > of and files related to numpy prior to installing. I also have tried > reinstalling python from source. Regardless, when I try import numpy, I get > the > following: > > Python 2.5.2 (r252:609

Re: [Numpy-discussion] Branch cuts, inf, nan, C99 compliance

Pauli Virtanen wrote: > Hi all, > > Re: Ticket 854. > > I wrote tests for the branch cuts for all complex arc* functions > in umathmodule. It turns out that all except arccosh were OK. > The formula for arcsinh was written in a non-standard form with > an unnecessary nc_neg, but this didn't affect

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

Michael Abbott wrote: > > I'm not actually convinced by the comment that's there now, which says > /* typecode will be NULL */ > but in truth it doesn't matter -- because of the correcly placed DECREF > after the PyArray_Scalar calls the routine no longer owns typecode. > I'm pretty sure

Re: [Numpy-discussion] ticket #842.

Stéfan van der Walt wrote: > 2008/7/19 Charles R Harris <[EMAIL PROTECTED]>: > >> In [2]: type(conjugate(array(8+7j))) >> Out[2]: >> >> In [3]: type((array(8+7j))) >> Out[3]: >> >> So I think all that needs to be done is fix the return type conjugate if we >> agree that it should be an array.

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

> I've attached a test script. Thank you! It looks like with that added DECREF, the reference count leak is gone.While it was a minor issue (it should be noted that reference counting errors on the built-in data-types won't cause issues), it is nice to clean these things up when we can.

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

Charles R Harris wrote: > > > On Fri, Jul 18, 2008 at 9:15 PM, Travis E. Oliphant > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > Michael Abbott wrote: > > Only half of my patch for this bug has gone into trunk, and > without the &

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

Charles R Harris wrote: > > > On Fri, Jul 18, 2008 at 9:15 PM, Travis E. Oliphant > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > Michael Abbott wrote: > > Only half of my patch for this bug has gone into trunk, and > without the &

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

Charles R Harris wrote: > > > On Fri, Jul 18, 2008 at 9:15 PM, Travis E. Oliphant > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > Michael Abbott wrote: > > Only half of my patch for this bug has gone into trunk, and > without the &

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

Charles R Harris wrote: > > > The reference leak seems specific to the float32 and complex64 types > called with default arguments. > > In [1]: import sys, gc > > In [2]: t = float32 > > In [3]: sys.getrefcount(dtype(t)) > Out[3]: 4 > > In [4]: for i in range(10) : t(); >...: > > In [5]: sys.g

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

Michael Abbott wrote: > Only half of my patch for this bug has gone into trunk, and without the > rest of my patch there remains a leak. > Thanks for your work Michael. I've been so grateful to have you and Chuck and others looking carefully at the code to fix its problems. In this particu

Re: [Numpy-discussion] Another reference count leak: ticket #848

> Looking at the uses of PyArray_FromAny I can see the motivation for this > design: core/include/numpy/ndarrayobject.h has a lot of calls which take a > value returned by PyArray_DescrFromType as argument. This has prompted me > to take a trawl through the code to see what else is going on, a

Re: [Numpy-discussion] snprintf vs PyOS_snprintf

Robert Kern wrote: > On Sat, Jul 12, 2008 at 13:11, Charles R Harris > <[EMAIL PROTECTED]> wrote: > >> Numpy uses a mix of snprintf and PyOS_snprintf. The Python version is there >> because snprintf wasn't part of the standard until C99. So either we should >> stick to the python version or make

Re: [Numpy-discussion] Another reference count leak: ticket #848

Michael Abbott wrote: > On Tue, 8 Jul 2008, Travis E. Oliphant wrote: > >> Michael Abbott wrote: >> >>> The attached patch fixes another reference count leak in the use of >>> PyArray_DescrFromType. >>> >>> >> The

Re: [Numpy-discussion] chararray behavior

Alan McIntyre wrote: > Since chararray doesn't currently have any tests, I'm writing some, > and I ran across a couple of things that didn't make sense to me: > > 1. The code for __mul__ is exactly the same as that for __rmul__; is > there any reason __rmul__ shouldn't just call __mul__? > Just

  1   2   3   4   >