What is it?
---
PyOpenCL makes the industry-standard OpenCL compute abstraction available from
Python.
PyOpenCL has been tested to work with AMD's and Nvidia's OpenCL
implementations and allows complete access to all features of the standard,
from a nice, Pythonic interface.
Where
On Montag 29 Dezember 2008, Robert Kern wrote:
You could wrap the wrappers in Python and check the dtype. You'd have
a similar bug if you passed a wrong non-object dtype, too.
Checking/communicating the dtype is something you always have to do
when using the 2.x buffer protocol. I'm inclined
Hi all,
I don't think PyObject pointers should be accessible via the buffer interface.
I'd throw an error, but maybe a (silenceable) warning would do. Would have
saved me some bug-hunting.
import numpy
numpy.array([55, (33,)], dtype=object)
x = numpy.array([55, (33,)], dtype=object)
x
On Montag 29 Dezember 2008, Robert Kern wrote:
On Sun, Dec 28, 2008 at 19:23, Andreas Klöckner li...@informa.tiker.net
wrote:
Hi all,
I don't think PyObject pointers should be accessible via the buffer
interface. I'd throw an error, but maybe a (silenceable) warning would
do. Would
On Montag 29 Dezember 2008, Robert Kern wrote:
On Sun, Dec 28, 2008 at 20:38, Andreas Klöckner li...@informa.tiker.net
wrote:
On Montag 29 Dezember 2008, Robert Kern wrote:
On Sun, Dec 28, 2008 at 19:23, Andreas Klöckner
li...@informa.tiker.net
wrote:
Hi all,
I don't think
Hi all,
I am happy to announce the availability of PyCuda [1,8], which is a
value-added Python wrapper around Nvidia's CUDA [2] GPU Computation
framework. In the presence of other wrapping modules [3,4], why would you
want to use PyCuda?
* It's designed to work and interact with numpy.
*
On Sonntag 22 Juni 2008, Kevin Jacobs [EMAIL PROTECTED] wrote:
Thanks for the clarification. That makes perfect sense. Do you have any
feelings on the relative performance of GPUArray versus CUBLAS?
Same. If you check out the past version of PyCuda that still has CUBLAS, there
are files
Hi all,
Is this supposed to be like that, i.e. is the fancy __setitem__ supposed to
not complain about unused assignees?
v = zeros((10,))
z = [1,2,5]
v[z] = [1,2,4,5]
v
array([ 0., 1., 2., 0., 0., 4., 0., 0., 0., 0.])
Contrast with:
v[1:3] = [1,2,3,4]
Traceback (most recent call
On Freitag 06 Juni 2008, Thomas Hrabe wrote:
Furthermore, I sometimes get a
Segmentation fault
Illegal instruction
and sometimes it works
It might be a memory leak, due to the segfault and the arbitrary behavior.?
Shameless plug: PyUblas [1] will take care of the nasty bits of wrapping C++
On Dienstag 29 April 2008, Lisandro Dalcin wrote:
Your implementation make uses of low level dlopening. Then, your are
going to have to manage all the oddities of runtime loading in the
different systems.
Argh. -1 for a hard dependency on dlopen(). At some point in my life, I might
be forced
On Dienstag 29 April 2008, David Cournapeau wrote:
Andreas Klöckner wrote:
Argh. -1 for a hard dependency on dlopen().
There is no hard dependency on dlopen, there is a hard dependency on
runtime loading, because well, that's the point of a plugin system. It
should not be difficult
On Dienstag 29 April 2008, David Cournapeau wrote:
Andreas Klöckner wrote:
Yes, obviously everything will need to be linked into one big static
executable blob. I am somewhat certain that distutils will be of no help
there, so I will need to roll my own. There is a CMake-based build
On Mittwoch 23 April 2008, Christopher Barker wrote:
NOTE:
Most folks now think that the pain of writing extensions completely by
hand is not worth it -- it's just too easy to make reference counting
mistakes, etc. Most folks are now using one of:
Cython (or Pyrex)
SWIG
ctypes
IMO, all of
On Mittwoch 23 April 2008, Christopher Barker wrote:
What's the status of the Boost array object? maintained? updated for
recent numpy?
The numeric.hpp included in Boost.Python is a joke. It does not use the native
API.
PyUblas [1] fills this gap, by allowing you to use Boost.Ublas on the C++
On Mittwoch 16 April 2008, Stéfan van der Walt wrote:
The inclusion of those cblas routines sounds like a good idea. Could
you describe which we need, and what would be required to get this
done?
Suppose cblas gets included in numpy, but for some reason someone decides to
link another copy
On Freitag 11 April 2008, Robert Kern wrote:
On Thu, Apr 10, 2008 at 10:57 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Turns out it matches the matlab definition. Maybe we just need another
function: vandermonde
-1 It's needless duplication.
Agree. Let's just live with Matlab's
On Mittwoch 26 März 2008, Charles R Harris wrote:
The docstring is incorrect. The Vandermonde matrix produced is compatible
with numpy polynomials that also go from high to low powers. I would have
done it the other way round, so index matched power, but that isn't how it
is.
Patch attached.
Hi Chuck, all,
On Mittwoch 09 April 2008, Charles R Harris wrote:
It would affect polyfit, where the powers correspond to the numpy
polynomial coefficients. That can be fixed, and as far as I can determine
that is the only numpy function that uses vander, but it might break some
software out
On Mittwoch 09 April 2008, Charles R Harris wrote:
import numpy.linalg as la ?
Yes! :)
Andreas
signature.asc
Description: This is a digitally signed message part.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
On Montag 07 April 2008, Robert Kern wrote:
I would prefer not to do it at all. We've just gotten people moved
over from Numeric; I'd hate to break their trust again.
+1.
IMO, numpy has arrived at a state where there's just enough namespace clutter
to allow most use cases to get by without
Hi Nadav,
On Montag 07 April 2008, Nadav Horesh wrote:
[snip]
Try something like this:
[atlas]
library_dirs = /users/kloeckner/mach/x86_64/pool/lib,/usr/lib
atlas_libs = lapack, f77blas, cblas, atlas
Andreas
signature.asc
Description: This is a digitally signed message part.
On Montag 07 April 2008, Stéfan van der Walt wrote:
I wouldn't exactly call 494 functions just enough namespace clutter;
I'd much prefer to have a clean api to work with.
Not to bicker, but...
import numpy
len(dir(numpy))
494
numpy.__version__
'1.0.4'
funcs = [s for s in dir(numpy) if
Hi all,
I'm having trouble getting numpy to compile something usable on a cluster I'm
using, in particular I see
8 -
ImportError:
/users/kloeckner/mach/x86_64/pool/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so:
undefined symbol:
I can answer my own question now:
1) Option --fcompiler=gnu95
2) Add the following to site.cfg
[atlas]
library_dirs = /users/kloeckner/mach/x86_64/pool/lib,/usr/lib
atlas_libs = lapack, f77blas, cblas, atlas
Andreas
On Sonntag 06 April 2008, Andreas Klöckner wrote:
Hi all,
I'm having
Hi all,
is there a particular reason why dot() and tensordot() don't have output
arguments?
Andreas
signature.asc
Description: This is a digitally signed message part.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
Hi all,
The docstring for vander() seems to contradict what the function does. In
particular, the columns in the vander() output seem reversed wrt its
docstring. I feel like one of the two needs to be fixed, or is there
something I'm not seeing?
This here is fresh from the Numpy examples
On Dienstag 25 März 2008, Nadav Horesh wrote:
scalars are immutable objects in python. Thus the += (and alike) are fake:
Again, thanks for the explanation. IMHO, whether or not they are fake is an
implementation detail. You shouldn't have to know Python's guts to be able to
use Numpy
Hi all,
I just got tripped up by this behavior in Numpy 1.0.4:
u = numpy.array([1,3])
v = numpy.array([0.2,0.1])
u+=v
u
array([1, 3])
I think this is highly undesirable and should be fixed, or at least warned
about. Opinions?
Andreas
signature.asc
Description: This is a digitally
On Montag 24 März 2008, Stéfan van der Walt wrote:
I think this is highly undesirable and should be fixed, or at least
warned about. Opinions?
I know the result is surprising, but it follows logically. You have
created two integers in memory, and now you add 0.2 and 0.1 to both --
not
On Dienstag 25 März 2008, Travis E. Oliphant wrote:
Question: If it's a known trap, why not change it?
It also has useful applications. Also, it can only happen at with a
bump in version number to 1.1
I'm not trying to make the functionality go away. I'm arguing that
int_array +=
30 matches
Mail list logo
