On 12/04/07, Stefan van der Walt [EMAIL PROTECTED] wrote:
Thank you for taking the time to write those tests!
Failures may be expressed using
NumpyTestCase.failIf(self, expr, msg=None)
That's not quite what I mean. There are situations, with the current
code, that it gets the answer wrong
On 11/04/07, Bill Baxter [EMAIL PROTECTED] wrote:
Must be pretty recent. I'm using 1.0.2.dev3520 (enthought egg) and
the function's not there.
It is.
I've never been quite happy with it, though; I realize it's not very
feasible to write one that efficiently checks all possible overlaps,
but
On 07/04/07, Steve Staneff [EMAIL PROTECTED] wrote:
Hi,
I'm looking for a better solution to managing a very large calculation.
Set A is composed of tuples a, each of the form a = [float, string]; set B
is composed of tuples of similar structure (b = [float, string]). For
each possible
On 07/04/07, Fernando Perez [EMAIL PROTECTED] wrote:
You are correct. If g,h in the OP's description satisfy:
a) they are bloody expensive
b) they release the GIL internally via the proper C API calls, which
means they are promising not to modify any shared python objects
the pure python
On 29/03/07, Robert Kern [EMAIL PROTECTED] wrote:
Glen W. Mabey wrote:
So, would that imply that a .copy() should be done first on any array
that you want to access .data on?
Or even ascontiguousarray().
I'd like to point out that the numpy usage of the word contiguous is
a bit
On 24/03/07, Bill Baxter [EMAIL PROTECTED] wrote:
Nice, but how does that fare on things like mdot(a,(b,c),d) ? I'm
pretty sure it doesn't handle it.
I think an mdot that can only multiply things left to right comes up
short compared to an infix operator that can easily use parentheses to
On 24/03/07, Travis Oliphant [EMAIL PROTECTED] wrote:
My opinion is that a 1-d array in matrix-multiplication should always be
interpreted as a row vector. Is this not what is currently done? If
not, then it is a bug in my mind.
An alternative approach, in line with the usual usage, is
On 24/03/07, Charles R Harris [EMAIL PROTECTED] wrote:
Yes indeed, this is an old complaint. Just having an infix operator would be
an improvement:
A dot B dot C
Not that I am suggesting dot in this regard ;) In particular, it wouldn't
parse without spaces. What about division? Matlab has
On 24/03/07, Bill Baxter [EMAIL PROTECTED] wrote:
I mentioned in another thread Travis started on the scipy list that I
would find it useful if there were a function like dot() that could
multiply more than just two things.
Here's a sample implementation called 'mdot'.
mdot(a,b,c,d) ==
On 23/03/07, Charles R Harris [EMAIL PROTECTED] wrote:
Anyone,
What is the easiest way to detect in python/C if an object is a subclass of
ndarray?
Um, how about isinstance or issubclass? (if you want strictness you
can look at whether x.__class__ is zeros(1).__class__)
Anne
On 21/03/07, Andrew Corrigan [EMAIL PROTECTED] wrote:
This is a feature I've been wanting for a long time, so I'm really glad that
Shane brought this up.
While I was hoping for a gain in speed, that isn't the only reason that I
would
like to see this added. In fact, the most compelling
On 21/03/07, Andrew Corrigan [EMAIL PROTECTED] wrote:
Thanks for pointing that out. Technically that works, but it doesn't really
express this operation as concisely and as naturally as I'd like to be able
to.
What I really want is to be able to write:
a = array([lambda x: x**2, lambda
On 15/03/07, Ray Schumacher [EMAIL PROTECTED] wrote:
The desired band is rather narrow, as the goal is to determine the f of a
peak that always occurs in a narrow band of about 1kHz around 7kHz
2) frequency shift, {low pass}, and downsample
By this I would take it to mean, multiply by a
On 09/03/07, Robert Kern [EMAIL PROTECTED] wrote:
Mark P. Miller wrote:
As an aside, are the random number generators from scipy.random the same
as those for numpy.random? If not, will those of us who need to just
use a few random numbers here and there throughout our code (we don't
need
On 07/03/07, Daniel Mahler [EMAIL PROTECTED] wrote:
My problem is not space, but time.
I am creating a small array over and over,
and this is turning out to be a bottleneck.
My experiments suggest that problem is the allocation,
not the random number generation.
Allocating all the arrays as
On 01/03/07, Francesc Altet [EMAIL PROTECTED] wrote:
Hi,
I don't think there is a solution for this, but perhaps anybody may
offer some idea. Given:
In [79]:a=numpy.arange(9,-1,-1)
In [80]:b=numpy.arange(10)
In [81]:numpy.random.shuffle(b)
In [82]:b
Out[82]:array([2, 6, 3, 5, 4, 9, 0, 8, 7,
On 27/02/07, Travis Oliphant [EMAIL PROTECTED] wrote:
The problem is that we aren't really specifying floating-point
standards, we are specifying float, double and long double as whatever
the compiler understands.
There are some platforms which don't follow the IEEE 754 standard.
This
On 23/02/07, Alexander Michael [EMAIL PROTECTED] wrote:
I still find the ring buffer solution appealing, but I did not see a
way to stack two arrays together without creating copies. Am I missing
a bit of numpy cleverness?
The short answer is no; the stride in memory from one element to the
On 21/02/07, Robert Kern [EMAIL PROTECTED] wrote:
Well, you can always use long double if it is implemented on your platform.
You
will have to construct a value for π yourself, though. I'm afraid that we
don't
really make that easy.
If the trig functions are implemented at all, you can
401 - 419 of 419 matches
Mail list logo
