David Cournapeau wrote:
> Andrew Straw wrote:
>
>> David Cournapeau wrote:
>>
>>
>>> - To send data from the calling process to matlab, you first have to
>>> create a mxArray, which is the basic matlab handler of a matlab array,
>>&g
David Cournapeau wrote:
> Andrew Straw wrote:
>
>> David Cournapeau wrote:
>>
>>
>>> - To send data from the calling process to matlab, you first have to
>>> create a mxArray, which is the basic matlab handler of a matlab array,
>>&g
David Cournapeau wrote:
> - To send data from the calling process to matlab, you first have to
> create a mxArray, which is the basic matlab handler of a matlab array,
> and populating it. Using mxArray is very ackward : you cannot create
> mxArray from existing data, you have to copy data t
Stefan van der Walt wrote:
> On Mon, Nov 06, 2006 at 02:09:32PM -0600, John Hunter wrote:
>
>> A simple import of numpy with the latest svn triggers a ctypes warning
>>
>> In [1]: import numpy
>> /usr/lib/python2.4/site-packages/numpy/ctypeslib.py:12: UserWarning:
>> All features of ctypes inter
Fernando Perez wrote:
> Here is some more info. We left a long-running job over the weekend
> with the prints you suggested. Oddly, something happened at the OS
> level which killed our SSH connection to that machine, but the above
> numpy dealloc() warning never printed (we logged this).
As an a
David Cournapeau wrote:
> I don't know anything about your device, but a driver directly accessing
> a memory buffer from a userland program sounds like a bug to me.
David, DMA memory (yes, I know thats an example of RAS Syndrome,
apologies) allows hardware to fill a chunk of RAM and then hand it
It sounds like your hardware drivers may be buggy -- you should only get
segfaults, not (the Windows equivalent of) kernel panics, when your
userspace code accesses wrong memory.
But if you have buggy hardware drivers, I suppose it's possible that
locking the memory will help. This wouldn't be the
Sven Schreiber wrote:
> Andrew Straw schrieb:
>
>
>> The matplotlib .deb on my website is working fine for me with the latest
>> numpy .deb there. If there are any recent patches or anything you are
>> missing, please let me know -- it's not really a big dea
Sven Schreiber wrote:
> Hi,
> as suggested on the website I use the kindly provided pre-built
> (unofficial) ubuntu debs. Recently there is a new one available with
> version numbe 1.0+~dev3336-0ads1.
>
> Apart from the slightly strange +~ thing in there, it very much seems to
> be based on trac ch
It is a wiki, and contributions are absolutely welcome, so please go
ahead and change it to be more clear.
Bill Baxter wrote:
>I think that's supposed to be covered by this line:
>"The default array data-type is now float64 (c double precision)
>instead of c integer."
>
>But yeh, I agree. It's d
William Grant wrote:
>Hi,
>
>I'm currently attempting to get scipy 0.5.1 into Ubuntu, however it
>currently cannot happen as numpy doesn't build with Python 2.5. I note
>that changeset 3109
>(http://projects.scipy.org/scipy/numpy/changeset/3109#file1) is meant to
>give 2.5 compatibility, but it is
Travis Oliphant wrote:
> Sebastian Haase wrote:
>
>> Travis Oliphant wrote:
>>
>>
>>
>>> It's not necessarily dead, the problem is complexity of implementation
>>> and more clarity about how all dtypes are supposed to be printed, not
>>> just this particular example. A patch would be
LANDRIU David SAp wrote:
> Hello,
>
> I come back to my question : how to use numarray
> with the numpy installation ?
>
> {ccali22}~(0)>setenv PYTHONPATH /usr/local/lib/python2.3/site-packages/numpy
>
Here's where you went wrong. You want:
setenv PYTHONPATH /usr/local/lib/python2.3/
The following code indicates there is a problem adding a numpy scalar
type to a Numeric array. Is this expected behavior or is there a bug
somewhere?
This bit me in the context of updating some of my code to numpy, while
part of it still uses Numeric.
import Numeric
import numpy
print 'Numeric._
Sven Schreiber wrote:
> Hi,
>
> Satya Upadhya schrieb:
>
>
> from Numeric import *
>
>
> Well this list is about the numpy package, but anyway...
>
This list is for numpy, numarray, and Numeric. There's just a lot more
numpy talk going on these days, but "numpy-discussion"
Dear Albert,
I have started to use numpy and ctypes together and I've been quite
pleased. Thanks for your efforts and writings on the wiki.
On the topic of ctypes but not directly following from your email: I
noticed immediately that the .ctypes attribute of an array is going to
be a de-facto arr
David wrote:
>Stephan Tolksdorf wrote:
>
>
>>Hi
>>
>>A user named jlc46 is misusing the wiki page "Installing SciPy/Windows"
>>to ask for help on his installation problems. How can I
>>a) contact him in order to ask him to post his questions on the mailing
>>lists, and
>>
>>
>
>You cannot
Tom Denniston wrote:
>Code that reproduces the problem:
>
>This is regular python:
>pickle.dumps(numpy.nan, 2)
>SystemError: frexp() result out of range
>
>This is fine in numpy:
>pickle.dumps(numpy.array([numpy.nan]), 2)
>
>This breaks:
>pickle.dumps(numpy.array([numpy.nan], numpy.PyObject), 2)
>
Travis Oliphant wrote:
> I'm still looking for ideas on version numbering.
>
> Right now, the trunk is at version 0.9.9 but this has bug-fixes from
> the 1.0b1 release. The next release will be 1.0b2 and should occur in
> about a week.
>
> I don't really like having the trunk use a 'lower' ver
Sasha wrote:
>On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
>
>
>
>>BTW, Fernando, all this is so that we can still have the svn revision
>>number in __version__, but so that it doesn't screw up sorting.
>>
>>
>
>Sorting __vers
Sasha wrote:
>On 7/24/06, Andrew Straw <[EMAIL PROTECTED]> wrote:
>[snip]
>
>
>>The concern is that there are a bazillion ways of sorting version
>>numbers but the version numbers from numpy's current svn tree don't sort
>>with (m)any of the
Sasha wrote:
>On 7/24/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
>
>>Andrew Straw has emphasized that the current strategy of appending the
>>SVN version number to development versions of the SVN tree makes it hard
>>to do version sorting.
>>
Michael Williams wrote:
>>Hi Andrew (and others),
>>
>>On Mon, Jun 19, 2006 at 09:32:44AM -0700, Andrew Straw wrote:
>>
>>
>
>
>>>>I have updated the apt repository I maintain for Ubuntu's Dapper, which
>>>>now includes:
>&g
GNU libc version 2.3.2 has a bug[1] "feclearexcept() error on CPUs with
SSE" (fixed in 2.3.3) which has been submitted to Debian[2] but not
fixed in sarge.
See http://www.its.caltech.edu/~astraw/coding.html#id3 for more
information and .debs which fix the problem.
[1] http://sources.redhat.com/bu
John Hunter wrote:
>>"Eric" == Eric Firing <[EMAIL PROTECTED]> writes:
>>
>>
>
>Eric> Correction: I did fix the first problem, and the second
>Eric> problem is not at all what I thought. Instead, the
>Eric> examples/data/lena.jpg file in my svn mpl directory is
Travis Oliphant wrote:
>Filip Wasilewski wrote:
>
>
>
>>Hi Travis,
>>
>>this is a great example of the __array_interface__ usage.
>>
>>
>>
>>
>>
>
>Just to complete the example:
>
>With the Image.py patch that adds the __array_interface__
>
>you can do
>
>import Image, pylab
>
>im = Image.o
Dear Fernando,
A couple of quick thoughts:
A) Despite my love of Pyrex, it probably isn't the tool for the job --
it doesn't play particularly well with C++, and it would require you to
write custom code for every function wrapped.
B) It sounds like you want something that will more-or-less
auto
An SVN checkout from a week or two ago looks OK on my amd64 machine:
[EMAIL PROTECTED]:~$ python
Python 2.4.3 (#2, Apr 27 2006, 14:43:32)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'0
David Cournapeau wrote:
> That's great. Last week, I sended several messages to the list
> regarding your messages about debian packages for numpy, but it looks
> they were lost somewhere
>
> Right now, I use the experimental package of debian + svn sources for
> numpy, and it works well. I
I have updated the apt repository I maintain for Ubuntu's Dapper, which
now includes:
numpy
matplotlib
scipy
Each package is from a recent SVN checkout and should thus be regarded
as "bleeding edge". The repository has a new URL:
http://debs.astraw.com/dapper/ I intend to keep this repository onl
I noticed in your note labeled 'June 16, 2006' that you refer to the
"desc" field. However, in the struct description above, there is only a
field named "descr".
Also, I suggest that you update the information in the comments of descr
field of the structure description to contain the fact that
Erin Sheldon wrote:
>Anyway - Recarrays have convenience attributes such that
>fields may be accessed through "." in additioin to
>the "field()" method. These attributes are designed for
>read only; one cannot alter the data through them.
>Yet they are writeable:
>
>
>
tr=numpy.recarray(10,
Dear Mary, I suggest using numpy and at the boundaries use
numpy.asarray(yourinput), which will be a quick way to view the data as
a numpy array, regardless of its original type. Otherwise, you could
look at the matplotlib distribution to see how it's done to really
support multiple array packages
OK, here's another (semi-crazy) idea:
__array_struct__ is the interface. ctypes lets us use it in "pure"
Python. We provide a "reference implementation" so that newbies don't
get segfaults.
___
Numpy-discussion mailing list
Numpy-discussion@lists.sou
Tim Hochberg wrote:
>Which of the following should we require for an object to be "supporting
>the array interface"? Here a producer is something that supplies
>array_struct or array_interface (where the latter is the Python level
>version of the former as per recent messages). Consumers do som
Travis Oliphant wrote:
> Andrew Straw wrote:
>
>> On the one hand, I feel we should keep __array_struct__ behaving
>> exactly as it is now. There's already lots of code that uses it, and
>> it's tremendously useful despite (because of?) it's simp
On the one hand, I feel we should keep __array_struct__ behaving exactly
as it is now. There's already lots of code that uses it, and it's
tremendously useful despite (because of?) it's simplicity. For these of
use cases, the __array_descr__ information has already proven
unnecessary. I must sa
Andrew Straw wrote:
>I've put together some .debs for numpy-0.9.8. There are binaries
>compiled for amd64 and i386 architectures of Ubuntu Dapper, and I
>suspect these will build from source for just about any Debian-based
>distro and architecture.
>
>
As usuall
Pau Gargallo wrote:
> is your effort somehow related to
> http://packages.debian.org/experimental/python/python2.3-numpy
> ?
>
> it is a bit out of date, but already in experimental.
>
I did have a look at their packaging infrastructure. It was breaking for
me with numpy-0.9.8, so I started my
Arnd Baecker wrote:
> What worries me is
> a) the Build conflicts: atlas3-base
>
I hoped to investigate further and post afterwards, but my preliminary
findings that led to this decision are:
1) building with atlas (atlas3-base and atlas3-base-dev) caused a
significant slowdown (~10x) on my s
I've put together some .debs for numpy-0.9.8. There are binaries
compiled for amd64 and i386 architectures of Ubuntu Dapper, and I
suspect these will build from source for just about any Debian-based
distro and architecture.
The URL is http://sefton.astraw.com/ubuntu/dapper and you would add th
Christopher Barker wrote:
> Joe Harrington wrote:
>
>> My
>> suggestion is that all the other pages be automatic redirects to the
>> scipy.org page or subpages thereof.
>>
+1
>
> if that means something like:
>
> www.numpy.scipy.org (or www.scipy.org/numpy )
>
> Then I'm all for it.
>
John, you want c.compressed().
John Hunter wrote:
>I'm a bit of an ma newbie. I have a 2D masked array R and want to
>extract the non-masked values in the last column. Below I use logical
>indexing, but I suspect there is a "built-in" way w/ masked arrays. I
>read through the docstring, but di
43 matches
Mail list logo
