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
this?
If you look at
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
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 sliced
Robert Kern wrote:
On Thu, Mar 12, 2009 at 01:34, Stéfan van der Walt ste...@sun.ac.za wrote:
2009/3/12 Robert Kern robert.k...@gmail.com:
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?
Darren Dale wrote:
On Mon, Mar 9, 2009 at 9:50 AM, Darren Dale dsdal...@gmail.com
mailto:dsdal...@gmail.com 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
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
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 stdin, line 1, in module
ValueError: size must be zero or positive
A working fix seemed to be this:
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 call last):
File stdin, line
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 A
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
Stéfan van der Walt wrote:
Hi Travis
2009/2/12 Travis E. Oliphant oliph...@enthought.com:
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.
Is there absolutely no way
Francesc Alted wrote:
A Saturday 07 February 2009, Neil escrigué:
Travis E. Oliphant oliphant at 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 improve
regularly.One feature that's been
Muhammad Alkarouri wrote:
--- On Wed, 21/1/09, Stéfan van der Walt ste...@sun.ac.za wrote:
From: Stéfan van der Walt ste...@sun.ac.za
...
You can also take a look at Ilan Schnell's bitarray:
http://pypi.python.org/pypi/bitarray/
Looks good to me. Thanks for the
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
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.
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's
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:
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 ?
Actually,
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
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
There
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 classes
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
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
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
Charles R Harris wrote:
On Sun, Nov 9, 2008 at 11:29 PM, T J [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 3:01 PM, T J [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 2:36 PM, Charles R Harris
[EMAIL PROTECTED]
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 can
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)
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 constructor
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
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.
Thanks for your report. I'm not sure why you are having trouble
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 for
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 shouldn't
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 that
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([ 0, 1075052544])
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 and
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 );
PyObject
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
dmitrey wrote:
let me also note that list(array((1))) returns
Traceback (innermost last):
File stdin, line 1, in module
TypeError: iteration over a 0-d array
D.
This is expected. 0-d arrays are currently not iterable.
-Travis
___
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-discussion
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 need to do
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 mailing list
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 returned, is there no way to
synchronize with other objects holding
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 do?
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)
{
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
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 functionality,
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;
s[1] = 1;
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):
output =
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 not
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 functions I need to implement and they need
to be generic and work
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
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
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
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 information
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 =
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
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 him to
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.
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 --
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 could
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.
It does not make
Charles R Harris wrote:
On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris
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 sum: I think 2, 3, 6, 7, 8, and 9 can be done immediately. 1) and
4) could
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 time. Wouldn't we want users to have access
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
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 makes
us
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.
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 see
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 signed type int by an
unsigned size_t
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.ctypeslib
* I'm fine with people needing to import numpy.ctypeslib to use
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
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 default but set
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
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 play well with
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 just
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
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 array
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 OOM
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:60911, Jul
Stéfan van der Walt wrote:
2008/7/19 Charles R Harris [EMAIL PROTECTED]:
In [2]: type(conjugate(array(8+7j)))
Out[2]: type 'numpy.complex128'
In [3]: type((array(8+7j)))
Out[3]: type 'numpy.ndarray'
So I think all that needs to be done is fix the return type conjugate if we
agree that
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 that
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 the
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, and
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
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]:
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
rest of my patch there remains a leak
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
rest of my patch there remains a leak
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
rest of my patch there remains a leak
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.
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 the
Michael Abbott wrote:
The attached patch fixes another reference count leak in the use of
PyArray_DescrFromType.
The first part of this patch is good. The second is not needed. Also,
it would be useful if you could write a test case that shows what is
leaking and how you determined
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
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 first part of this patch is good. The second is not needed.
I don't see
Dag Sverre Seljebotn wrote:
I'd like some advice for what way people feel would be the best for
supporting complex datatypes in NumPy in Cython; as well as ask in what
way it is likely that NumPy will make use of PEP 3118.
It seems like NumPy defines its complex data to be a struct of two
Charles R Harris wrote:
Questions about ticket #390
http://projects.scipy.org/scipy/numpy/ticket/390 :
1. Should we fix this for 1.2?
+1
2. Is the attached patch the correct fix for this?
It looks good, except for the rare case where the array contains the
word rec Perhaps the fix should
Robert Kern wrote:
The only inconsistency I can see here is that x.item() gives a tuple
rather than a scalar record. A scalar record does have field access,
but the tuple doesn't.
In [28]: x.item()['a']
.item() always returns a standard Python type. So, this is expected
behavior.
If
Charles R Harris wrote:
On Wed, Jun 25, 2008 at 2:04 PM, Neil Muller
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
On Wed, Jun 25, 2008 at 7:53 PM, Charles R Harris
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
But I wonder if this case isn't supposed to be caught by
Yes, but it is directed at the interpreter, which will raise a
TypeError if needed. But the interpreter doesn't know that some
generic function might return NotImplemented and wouldn't know what to
do if it did. What the user should see when they call something like
right_shift(a,b) and
Stéfan van der Walt wrote:
Hi all,
I am documenting `recarray`, and have a question:
Is its use still recommended, or has it been superseded by fancy data-types?
I rarely recommend it's use (but some people do like attribute access to
the fields).It is wrong, however, to say that
So it has a numeric value?
Yes, it's just a floating point number. It's not a very elegant thing,
but it does allow some ability to specify an ordering.
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
1 - 100 of 290 matches
Mail list logo
