Tim Hochberg wrote:
A. M. Archibald wrote:
[SNIP]
Really it would be nice if what vectorize() returned were effectively
a ufunc, supporting all the various operations we might want from a
ufunc (albeit inefficiently). This should not be difficult, but I am
not up to writing
Christopher Barker wrote:
[SNIP]
I think the PEP has far more chances of success if it's seen as a
request from a variety of package developers, not just the numpy crowd
(which, after all, already has numpy
This seems eminently sensible. Getting a few developers from other
projects on board
Ivan Vilata i Balaguer wrote:
Hi all,
I noticed that the set of ``where()`` functions defined by Numexpr all
have a signature like ``xfxx``, i.e. the first argument is a float and
the return, second and third arguments are of the same type (whatever it
is).
Since the first argument
Ivan Vilata i Balaguer wrote:
Tim Hochberg (el 2006-12-20 a les 09:20:01 -0700) va dir::
Actually, this is on purpose. Numpy.where (and most other switching
constructs in Python) will switch on almost anything. In particular, any
number that is nonzero is considered True, zero
I was just going to try pyrex out with numpy to see how it compares with
weave (which is cool but quirky). My first attempt ended in failure: I
tried to compile the demo in in numpy/doc/pyrex and got this error:
c_numpy.pxd:99:22: Array element cannot be a Python object
Does anyone who
Abel Daniel wrote:
Robert Kern robert.kern at gmail.com writes:
Abel Daniel wrote:
Now, I think that having a way of getting an element-wise comparison
(i.e. getting an array of bools) is great. _But_ why make that the
result of a '==' comparison? Is there any actual code that
Robert Kern wrote:
Christopher Barker wrote:
Robert Kern wrote:
[SNIP]
I copied the algorithm from Python's random
module. At the core of it is a set of swaps:
x[i], x[j] = x[j], x[i]
With the kind of sequences that the stdlib random module is expecting, that
makes perfect
