Since some months now the latest scipy (0.5.1) binary (for Windows) is not
compatible with current numpy (1.0) - obviously because of a C-library mismatch.
Does somebody have a compatible binary - or when is the next scipy (binary)
planned?
Robert
Alan G Isaac wrote:
rr=N.array(zip(range(20),range(20)))
pid = N.random.permutation(rr.shape[0])
rr=rr[pid]
rr
array([[ 9, 9],
[ 2, 2],
[ 3, 3],
[15, 15],
[ 4, 4],
[11, 11],
[18, 18],
[17, 17],
[ 5, 5],
[12, 12],
(Reposting to numpy-discussion@scipy.org instead of the SourceForge list.)
It is my understanding that Numpy has lite versions of BLAS and LAPACK
that it will use if it cannot find system libraries. Is it possible to FORCE
it to use the lite versions rather than existing system libraries?
Christopher Barker wrote:
Robert Kern wrote:
This is really a thinko on my part.
What, exactly, is a thinko?
Like a typo except that the fault lies with the brain, not the fingers.
I copied the algorithm from Python's random
module. At the core of it is a set of swaps:
x[i], x[j] =
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
Robert Kern wrote:
I don't want to assume that the only two sequence types are lists and arrays.
Does numpy.random.shuffle really have to work on any sequence? and
without making a copy? I'm not so sure -- having num* functions operate
on any sequence has been a design goal of Numeric from the
On 22 Nov 2006 16:44:07 -
[EMAIL PROTECTED] wrote:
(Reposting to numpy-discussion@scipy.org instead of the SourceForge list.)
It is my understanding that Numpy has lite versions of BLAS and LAPACK
that it will use if it cannot find system libraries. Is it possible to FORCE
it to use
Robert Kern wrote:
Tim Hochberg wrote:
Robert Kern wrote:
One possibility is to check if the object is an ndarray (or subclass) and
use
.copy() if so; otherwise, use the current implementation and hope that you
didn't pass it a Numeric or numarray array (or some other view-based
Unfortunately if the value is changed to masked, this is not updated
in the parent array. This seems very inconsistent. I don't view masked
values any different than any other value.
Inconsistent, maybe, useful definitely:
Masking a view and getting the original masked accordingly could