Here is a new update. I added the PY_POINTER, and PY_ARRAYOF
specifications to simplify the extended specification and allow memory
that is a pointer to another memory.
This should be the last update today.
-Travis
PEP: unassigned
Title: Extending the buffer protocol to include the array
Vincent Broman wrote:
My build of numpy fails under Yellow Dog Linux 2.1,
running on a powerpc multiprocessor board from Curtiss-Wright.
Its kernel is 2.4.19-Asmp tailored by the vendor.
The gcc compiler is configured as ppc-yellowdog-linux with
version number 2.95.3 20010111.
The python
killian koepsell wrote:
hi,
the von mises distribution in numpy.random seems to be biased towards
a higher concentration (kappa). given a concentration of 2, it
produces data that has a concentration of 2.36. i compared the
distribution to the one produced by the CircStats[1] package of R[2]
Christopher Barker wrote:
[OT: why the heck do none of the SWIG docs give examples (or even
suggest) using distutils for building SWIG extensions???]
I'm pretty sure this is because the people who contributed to the SWIG
docs the most are not currently using numpy.distutils (but probably
nd to copy hundres of MB around unnecessarily.
I think it is a real shame that boost currently doesn't properly support numpy
out of the box, although numpy has long obsoleted both numarray and Numeric
(which is both buggy and completely unsupported). All the more so since
writing
Timothy Hochberg wrote:
On 9/11/07, *Robert Kern* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Mike Ressler wrote:
The following seems to be a wart: is it expected?
Set up a 10x10 array and some indexing arrays:
a=arange(100)
a.shape=(10,10)
David Cournapeau wrote:
Hi,
I would like to know whether I could request svn write access to
numpy svn. There are several things I would like to work on which are
big enough so that just patch would be difficult, and branches more
appropriate, and my understanding is that svn branches
Tom Denniston wrote:
Sometimes numpy operationrs result in NotImplementedType. It makes it
a little hard to debug because the problem then crops up later when
you try to do an operation with the NotImplementedType. Does anyone
know of a way to get numpy to raise instead of returning not
Arnar Flatberg wrote:
However, when I tried to to insert a 1-dim array with a 'two-dim'
index things went wrong:
a[[0],:] = [2,2]
Segmentation fault
I do not see this error in latest trunk of numpy (I suspect it's also
not there in the latest release).
Am I just a
Christopher Hanley wrote:
Hi,
The latest version of numpy has a unit test failure on big endian machines.
Thanks Chris,
Do you know which version last succeeded?
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
David Cournapeau wrote:
Hi,
Starting thinking over the whole distutils thing, I was thinking
what people would think about using scons inside distutils to build
extension. The more I think about it, the more I think than distutils
not being maintained, and numpy/scipy building needs being
Jörgen Stenarson wrote:
Hi,
I cannot compile numpy (rev 2042) for python2.4 on win32, it works on
python2.5. It looks like the call to function get_build_architecture in
distutils.misc_util.py is python2.5 specific.
Yes. This needs to be fixed. I'll do it.
Can you try the current
Neal Becker wrote:
Matthieu Brucher wrote:
2007/10/12, Alan G Isaac [EMAIL PROTECTED]:
On Fri, 12 Oct 2007, Matthieu Brucher apparently wrote:
I'm trying to understand (but perhaps everything is in the
numpy book in which case I'd rather buy the book
immediately) how to
Matthieu Brucher wrote:
Hi
I keep on getting this error :
*** Reference count error detected:
an attempt was made to deallocate 7 (l) ***
It happens on numpy calls (multiplications, call to inner(), ...), but
I didn't find the real reason. I'm using Numpy ' 1.0.4.dev3875' with
Python
Matthieu Brucher wrote:
The problem is that there is a data-type reference counting error some
where that is attempting to deallocate the built-in data-type 'l'
That's what I supposed, but I couldn't find the reason why it wanted
to do this
It's not really a Python error
Giles Thomas wrote:
Hi,
At Resolver Systems, we have a product that is written in IronPython -
the .NET Python implementation - and allows users to use that language
to script a spreadsheet-like interface. Because they're using
IronPython, they can access their existing .NET objects and
Sebastian Haase wrote:
Hi,
there is a way of doing this. As far as I know, you have to create
your own version of numpy arrays. E. g. try this:
class myNumpy(numpy.ndarray):
pass
Then creating an instance as in
a = myNumpy(otherNumpyArray)
would make `a` behave just like any other
David Cournapeau wrote:
Hi Jarrod,
Would it be possible to merge some of the work I have done recently
concerning cleaning configuration and so on (If nobody is against it, of
course) ? If this is considerer too big of a change, what is the plan
for a 1.1 release, if any ?
Travis E. Oliphant wrote:
We can't change the C-API for PyArray_FromAny to accept an alignment
flag, and I'm pretty loath to do that even for 1.1.
Ooops! Pleas read that as can't accept an alignment *argument*
-Travis
___
Numpy-discussion
I've finally caught up with the discussion on aligned allocators for
NumPy. In general I'm favorable to the idea, although it is not as
easy to implement in 1.0.X because of the need to possibly change the C-API.
The Python solution is workable and would just require a function call
on the
Anne Archibald wrote:
On 26/10/2007, Georg Holzmann [EMAIL PROTECTED] wrote:
if in that example I also change the strides:
int s = tmp-strides[1];
tmp-strides[0] = s;
tmp-strides[1] = s * dim0[0];
Then I get in python the fortran-style array in right order.
This is
An IronPython compatible version of NumPy would be great.Of course
it could be done by using C# to write NumPy, but I'm not sure that this
would really be any less work than creating a glue layer that allowed
most (or all) C-Python extensions to work with IronPython.
I'm curious
Karol Langner wrote:
I opened a ticket for this (#602). Hopefully someone will confirm that adding
that Py_DECREF call fixes the leak and someone with write access patches it
in svn.
Thanks for looking into this and isolating the problem...
-Travis O.
John Hunter wrote:
A colleague of mine just asked for help with a pesky bug that turned
out to be caused by his use of a list of booleans rather than an array
of booleans as his logical indexing mask. I assume this is a feature
and not a bug, but it certainly surprised him:
In [58]: mask =
Benjamin M. Schwartz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NumPy is included in the OLPC operating system, which is very constrained in
space. Therefore, it would be nice to remove some subpackages to save a few
megabytes. For example, the system does not include any Fortran
Hans Meine wrote:
Hi!
I wonder why simple elementwise operations like a * 2 or a + 1 are not
performed in order of increasing memory addresses in order to exploit CPU
caches etc.
C-order is special in NumPy due to the history. I agree that it
doesn't need to be and we have taken
Christopher Barker wrote:
This discussion makes me wonder if the basic element-wise operations
could (should?) be special cased for contiguous arrays, reducing them to
simple pointer incrementing from the start to the finish of the data
block. The same code would work for C and Fortran
David Cournapeau wrote:
Travis E. Oliphant wrote:
I wasn't talking about the min, mean, and max methods specifically.
These are all implemented with the reduce method of a ufunc.
Ah, my mistake, I wrongly understood only some of them were implemented
through ufunc
Hans Meine wrote:
Fortran order arrays can be preserved but it takes a little extra work
because backward compatible expectations had to be met. See for example
the order argument to the copy method of arrays.
What do you mean exactly (if you have something specific in mind at
Geoffrey Zhu wrote:
Very interesting! If I use the MSI file, numpy.test() hangs. If,
however, I use the EGG file, it is actually fine.
Can you find the md5sum of these files?
There is a md5sum.exe at
http://www.etree.org/md5com.html
It would be good to verify that you have the correct
David Cournapeau wrote:
Hi,
I would appreciate to get some comment on whether there is any
chance to get my numpy.scons branch merge into the trunk at some near
future. I feel to have reached the point where the only big thing
missing is more testing. I tried to test it on many
Michael McNeil Forbes wrote:
Why are numpy warnings printed rather than issued using the standard
warnings library? I know that the behaviour can be controlled by
seterr(), but it seem rather unpythonic not to use the warnings library.
The warn option explicitly allows you to use the
Sameer DCosta wrote:
I'm trying to convert a character array to a floating point array. I'm
using one of the recent svn builds. It is surprising that astype does
not do the job. However if I first convert the char array to an array
and then use astype everything works fine. Is this a bug?
Hans Meine wrote:
Hi!
Is there a way to query the minimum and maximum values of the numpy datatypes?
numpy.iinfo (notice the two i's) (integer information)
numpy.finfo (floating point information)
Example:
numpy.iinfo(numpy.uint8).max
numpy.iinfo(numpy.int16).min
You pass the datatype
Fernando Perez wrote:
On Dec 10, 2007 4:41 PM, Robert Kern [EMAIL PROTECTED] wrote:
The current situation is untenable. I will gladly accept a slow BLAS for an
official binary that won't segfault anywhere. We can look for a faster BLAS
later.
Just to add a note to this: John
Hans Meine wrote:
On Dienstag 11 Dezember 2007, Timothy Hochberg wrote:
You mean one of the following?
a.clip(min = 10, max = numpy.finfo(a.dtype).max)
a.clip(min = 10, max = numpy.iinfo(a.dtype).max)
No. I mean:
numpy.maximum(a, 10)
To correspond to the above example.
Fernando Perez wrote:
I will put new binaries on the sourceforge site this weekend for both
NumPy 1.0.4 and SciPy 0.6.0. I should be able to find an old PIII
WinXP machine around somewhere, which I will devote to building the
official non-SSE2 releases from here on out.
Great, many
Christian Meesters wrote:
Hi,
For compatibility reasons (work with Biopython) I would like to use to
Numeric in some code of mine. (Of course, I could make a little detour
converting into numpy.array, but first I wonder whether somebody might
know a solution for the problem with Numeric.)
Hi all,
We had a great Sprint at Berkeley over last weekend. Jarrod deserves a
huge hand for organizing it and Fernando should be also congradulated
for making the Sprint a productive communication session with a lot of
different people.
Going forward, there will be a relatively informal
Stuart Brorson wrote:
Hi --
I have found a bug in numpy-1.0.4. The bug is a crash when doing
linalg.inv() on a Windows machine. The machine is an old Pentium 3
machine. The error report indicates an invalid op code. Details
about this bug are in the numpy tracker under ticket 635.
Hi all,
The postfix service on the server hosting several of the mailing lists
was down since Monday. Mails to the list were preserved and archived
but were not being distributed to subscribers. We restarted the
postfix service and messages should now be going out.
Apologies for the
David Cournapeau wrote:
Hi,
as discussed with some other numpy developers, in particular Travis, I
started to prepare my work related to scons for step-by-step merging
into the trunk. The first step is done, and is in cleanconfig_rtm
branch (rtm for ready to merge).
This branch basically:
Stefan van der Walt wrote:
Hi Travis,
During the sprint I also merged Pierre's MaskedArray code into the
maskedarray branch. That is nearly done, with only a few unit tests
still failing -- ones brought over from the old numpy.ma.
This is mainly due to some changes in the API, for example
Pierre GM wrote:
All,
I'd like to move forward with it sooner (for 1.0.5) if the API changes
are not drastic. Although ideally 0 API changes would be desireable,
I'm not sure if that is feasible. Are put and putmask the only changes
in the API. What are the rest of them?
Ondrej Certik wrote:
Hi,
I need to write 2D Ising model simulation into my school, so I wrote
it in Python, then rewrote it in Fortran + f2py, and also Cython:
http://hg.sharesource.org/isingmodel/
And Cython solution is 2x faster than f2py. I understand, that I am
comparing many things -
Doc-day will start tomorrow (in about 12 hours). It will be Friday for
much of America and be moving into Saturday for Europe and Asia. Join
in on the irc.freenode.net (channel scipy) to coordinate effort. I
imaging people will be in an out. I plan on being available in IRC from
about
Stefan van der Walt wrote:
On Thu, Dec 27, 2007 at 09:27:09PM -0800, Jarrod Millman wrote:
On Dec 27, 2007 7:42 PM, Travis E. Oliphant [EMAIL PROTECTED] wrote:
Doc-day will start tomorrow (in about 12 hours). It will be Friday for
much of America and be moving into Saturday
Charles R Harris wrote:
On Dec 29, 2007 7:59 PM, Fernando Perez [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Dec 29, 2007 6:51 PM, Charles R Harris
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
If not, we should
definitely decide on the structure of the
Neal Becker wrote:
I'm looking at writing some c++ code to interoperate with numpy. A c++
random access iterator must include a 'distance' function. distance (i1,
i2) must return the number of times i1 has to be incremented to reach i2.
Is there a way to get this from PyArrayIterObject?
Charles R Harris wrote:
On Jan 4, 2008 11:13 AM, Pearu Peterson [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Fri, January 4, 2008 7:33 pm, Travis E. Oliphant wrote:
So, create an empty object array and insert the entries the way
you want
them
David M. Cooke wrote:
On Jan 4, 2008, at 13:58 , Fernando Perez wrote:
My vote so far is for hg, for performance reasons but also partly
because sage and sympy already use it, two projects I'm likely to
interact a lot with and that are squarely in line with the
Robert Kern wrote:
Travis E. Oliphant wrote:
I don't think it is time to move wholesale to something like Mercurial
or bzr. I would prefer it if all of the Enthought-hosted projects
moved to the (new) system at once, which is not going to happen in the
short term (but long term
Bruce Sherwood wrote:
Okay, I've implemented the scheme below that was proposed by Scott
Daniels on the VPython mailing list, and it solves my problem. It's also
much faster than using numpy directly: even with the def and if
overhead: sqrt(scalar) is over 3 times faster than the numpy
Charles R Harris wrote:
Hi All,
I'm thinking that one way to make the automatic type conversion a bit
safer to use would be to add a CASTABLE flag to arrays. Then we could
write something like
a[...] = typecast(b)
where typecast returns a view of b with the CASTABLE flag set so that
Darren Dale wrote:
One of my collaborators would like to use 16bit float arrays. According to
http://www.scipy.org/Tentative_NumPy_Tutorial, and references to float16 in
numpy.core.numerictypes, it appears that this should be possible, but the
following doesnt work:
No, it's only
Andrew Straw wrote:
Travis E. Oliphant wrote:
Andrew Straw wrote:
Hi,
I'm forwarding a bug from PyOpenGL. The developer, Mike Fletcher, is
having troubles accessing a numpy scalar with the __array_interface__.
Is this supposed to work? Or should __array_interface__ trigger
Andrew Straw wrote:
Hi,
I'm forwarding a bug from PyOpenGL. The developer, Mike Fletcher, is
having troubles accessing a numpy scalar with the __array_interface__.
Is this supposed to work? Or should __array_interface__ trigger an
AttributeError on a numpy scalar? Note that I haven't done
Robert Kern wrote:
Neal Becker wrote:
I noticed that if I generate complex rv i.i.d. with var=1, that numpy says:
var (real part) - (close to 1.0)
var (imag part) - (close to 1.0)
but
var (complex array) - (close to complex 0)
Is that not a strange definition?
2. Take a
Neal Becker wrote:
Where can I find a (hopefully simple) example of c-code for a ufunc?
Probably in scipy.special and or umathmodule.c in numpy/core/src. The
key is to register a 1-d inner loop that performs the basic
calculation for a particular data-type.
You also need to provide the
Stefan van der Walt wrote:
Hi all,
We currently use an array scalar of value False as the mask in
MaskedArray. I would like to make sure that the mask value cannot be
modified, but when I try
import numpy as np
x = np.bool_(False)
x.flags['WRITEABLE'] = False
I am warned that you
Matthew Brett wrote:
Hi,
I've just finished moving the scipy tests over to nose.
Thinking about it, it seems to me to be a good idea to do the same for numpy.
We talked about this at the SciPy Sprint. Eventually, we will get
there. However, if we do it before 1.0.5, it will require
Ryan May wrote:
Hi,
Can someone explain the reference counting wrt using ctypes and numpy.
Specifically, I have code like:
from ctypes import *
import numpy as N
class Data(Structure):
_fields_=[('var',POINTER(c_float))]
d = Data()
d.var = N.arange(100.,
Peter Ward wrote:
Hi,
I have been trying to build numpy on an opteron based Solaris 10
machine, with poor results.
After skimming over the discussion archives I noticed a branch for
numpy.sunperf in the svn repository.
Unfortunately this is no longer available, so I was curious as to
Clarke, Trevor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm calling some python code from a C++ app via an intermediary library
(i.e. I can't directly create Python C objects like Buffers). I'm
passing a void* (cast to a long) to the python method and I'd like to
use numpy to
Travis E. Oliphant wrote:
Clarke, Trevor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm calling some python code from a C++ app via an intermediary library
(i.e. I can't directly create Python C objects like Buffers). I'm
passing a void* (cast to a long) to the python method
Thomas Heller wrote:
Travis E. Oliphant schrieb:
Thomas Heller wrote:
I am experimenting with implementing __array_interface__ and/or
__array_struct__
properties for ctypes instances, and have problems to create numpy arrays
from them that share the memory. Probably I'm doing
Bill Spotz wrote:
Hi,
I am currently using PyArray_FromObject() to convert an input
argument to a 32-bit integer array. On a 64-bit architecture, it is
easy to create an integer array whose default type is 64-bit. When
this is sent to PyArray_FromObject(), it raises an error, saying
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Tom Johnson wrote:
Hi, I'm having some troubles with long.
from numpy import log
log(8463186938969424928L)
43.5822574833
log(10454852688145851272L)
type 'exceptions.AttributeError': 'long' object has no attribute 'log'
The problem is that the latter long
Matthew Brett wrote:
Hi,
http://projects.scipy.org/scipy/numpy/browser/branches/build_with_scons/
Excellent idea - and congratulations to David for all his hard work -
but this is a large change, and I wonder if we need more time with the
scons build system in the svn trunk?
Matthew Brett wrote:
Hi,
median moved mediandim0
implementation of medianwithaxis or similar, with same call
signature as mean.
But - for the median function change - do we agree that this should be
changed? I think it is a significant wart in the numpy API, and has
caught
Joris De Ridder wrote:
On 30 Jan 2008, at 00:32, Travis E. Oliphant wrote:
Matthew Brett wrote:
Hi,
median moved mediandim0
implementation of medianwithaxis or similar, with same call
signature as mean.
But - for the median function change - do we agree
Timothy Hochberg wrote:
On Jan 29, 2008 5:48 PM, Travis E. Oliphant [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Joris De Ridder wrote:
On 30 Jan 2008, at 00:32, Travis E. Oliphant wrote:
Matthew Brett wrote:
Hi,
median moved
James Philbin wrote:
I can't fathom where the comparison functions exist in the code. It
seems that the comparison signature is of the form (void*, void*,
PyArrayObject*), so it doesn't seem possible at the moment to specify
a compare function which can reason about the underlying types of the
James Philbin wrote:
I can't fathom where the comparison functions exist in the code. It
seems that the comparison signature is of the form (void*, void*,
PyArrayObject*), so it doesn't seem possible at the moment to specify
a compare function which can reason about the underlying types of the
Stuart Brorson wrote:
Anyway, since NumPy is committed to (Re, Im) as the base
representation of complex numbers, then it is not unreasonable to
implement round, fix, and so on, by operating independently on the Re
and Im parts.
Or am I wrong?
Sounds reasonable to me...
-Travis O.
Chris Ball wrote:
Hi,
I'm having some trouble accessing elements in an array of dtype=O
from C code; I hope someone on the list could give me some advice
(because I might be doing something stupid).
I have an array of simple objects, created as follows:
class CF(object):
def
Charles R Harris wrote:
Travis,
I notice that you used PyDataMem_NEW, PyDimMem_NEW, and friends to
allocate memory in the sort routines. Is there a good reason to use
these rather than malloc?
Only to allow for the possibility of different allocation routines.
There is an option to use
Hi everybody,
In writing some generic code, I've encountered situations where it would
reduce code complexity to allow NumPy scalars to be indexed in the
same number of limited ways, that 0-d arrays support.
For example, 0-d arrays can be indexed with
* Boolean masks
* Ellipses
Konrad Hinsen wrote:
On 21.02.2008, at 08:41, Francesc Altet wrote:
Well, it seems like a non-intrusive modification, but I like the
scalars
to remain un-indexable, mainly because it would be useful to raise an
error when you are trying to index them. In fact, I thought that when
you
Damian Eads wrote:
While we are on the subject of indexing... I use xranges all over the
place because I tend to loop over big data sets. Thus I try avoid to
avoid allocating large chunks of memory unnecessarily with range. While
I try to be careful not to let xranges propagate to the
Konrad Hinsen wrote:
On 22.02.2008, at 01:10, Alan G Isaac wrote:
Someone once pointed out on this list that one might
consider a matrix to be a container of 1d vectors. For NumPy,
however, it is natural that it be a container of 1d arrays.
(See the discussion for the distinction.)
Could you explain to me how you'd like this to be fixed? If the
matrix becomes a container of 1-d arrays, then you can no longer
expect x[:,0] to return a column vector -- which was one
of the reasons the matrix class was created. While not
entirely consistent, one workaround would be
On Fri, 22 Feb 2008, Stefan van der Walt apparently wrote:
This is exactly what I would expect for matrices: M[0] is
the first row of the matrix.
Define what first row means!
Konrad has shown that do get it right you really have to introduce
three separate things (matrices,
Alan G Isaac wrote:
stop believing that M[0][0] and M[0,0] should return the
same thing. There is nothing in Python that requires
this.
I never suggested there is.
My question how to guess? does not imply that.
My point is: the matrix object could have more intuitive
behavior
Neal Becker wrote:
Now that I have my user-defined type, I want to add some funcs.
According to the numpy book, I need to use:
PyUFunc_RegisterLoopForType
The book says I first need a ufunc. The only way I see to create one is
PyUFunc_FromFuncAndData.
Is the the correct procedure?
Ondrej Certik wrote:
Hi,
more details in this bug report.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467095
The bug report offers a fix for this problem. It seems to me this is
not fixed even in the latest svn.
Is there a ticket on the NumPy trac for this? We won't see it if
Christopher Hanley wrote:
Robert Kern wrote:
On Tue, Feb 26, 2008 at 12:09 PM, Christopher Hanley [EMAIL PROTECTED]
wrote:
Robert Kern wrote:
On Tue, Feb 26, 2008 at 11:50 AM, Christopher Hanley [EMAIL PROTECTED]
wrote:
Greetings,
I was wondering if within the last 8
Neal Becker wrote:
Travis E. Oliphant wrote:
The code for this is a bit hard to understand. It does appear that it only
searches for a conversion on the 2nd argument. I don't think that's
desirable behavior.
What I'm wondering is, this works fine for builtin types. What
Lisandro Dalcin wrote:
Well, after all that said, I'm also fine with either approach. Anyway,
I would say that my personal preference is for the one using
'str.index', as it is the simplest one regarding the old code.
Like Christopher, I rarelly (never?) use 'loadtxt'. But this issue
made a
Sameer DCosta wrote:
Hi,
I'm having trouble renaming record array fields if they contain object
arrays in them. I followed the solutions posted by Robert Kern and
Stefan van der Walt (Thanks again) but it doesn't look like this
method works in all cases. For reference:
Thomas Grill wrote:
Hi all,
i did some profiling on OS X/Intel 10.5 (numpy 1.0.4) and was
surprised to find calls to the system function feclearexcept to be by
far the biggest cpu hog, taking away about 30% of the cpu in my case.
Would it be possible to change UFUNC_CHECK_STATUS in
Travis E. Oliphant wrote:
Neal Becker wrote:
Travis E. Oliphant wrote:
The code for this is a bit hard to understand. It does appear that it only
searches for a conversion on the 2nd argument. I don't think that's
desirable behavior.
What I'm wondering is, this works fine
Scott Ransom wrote:
Hi Travis,
That fixes the problem that I reported such that there is no glibc
issue anymore.
However, it does result in a change in behaviour for fromfile.
Previously, when no data was returned an exception was raised.
With the new fix there is no exception, and an
Alan G Isaac wrote:
I never got a response to this:
URL:http://projects.scipy.org/pipermail/scipy-dev/2008-February/008424.html
(Two different types claim to be numpy.int32.)
It's not a bug :-) There are two c-level types that are both 32-bit (on
32-bit systems).
-Travis
Charles R Harris wrote:
On Mon, Mar 3, 2008 at 10:21 AM, Jarrod Millman [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hello,
I would like to tag the 1.0.5 release on Wednesday night and announce
the release by Monday (3/10). If you have anything that you would
like
Revaz Yves wrote:
Matthieu Brucher wrote:
Hi,
What type is pos-dimensions in your case ? It may be long (64bits
long) instead of the expected int (32bits) or something like that ?
yes,
pos-dimensions is a 64bits long
while PyArray_FromDims expects 32bits int.
Why is it so ?
Giorgio F. Gilestro wrote:
Hi Everybody,
I have some arrays that sometimes need to have some of their values
masked away or, simply said, not considered during manipulation.
I tried to fulfill my purposes using both NaNs and MaskedArray but
neither of them really helped completely.
Let's
Zbyszek Szmek wrote:
On Thu, Mar 13, 2008 at 05:44:54PM -0400, Alan G Isaac wrote:
Looks like I misunderstood your question:
you want an **array** of strings?
In principle you should be able to use ``fromiter``,
I believe, but it does not work. BUG? (Crasher.)
import numpy as N
Neal Becker wrote:
In arrayobject.c, various complex functions (e.g., array_imag_get) use:
PyArray_ISCOMPLEX - PyTypeNum_ISCOMPLEX,
which is hard coded to 2 predefined types :(
If PyArray_ISCOMPLEX allowed user-defined types, I'm guessing functions such
as array_imag_get would just work?
1 - 100 of 290 matches
Mail list logo
