On Mon, Jun 9, 2008 at 3:41 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
I suggest we also remove ParametricTestCase now.
I don't mind converting the existing uses (looks like it's only used 5
times) to something else, it was causing trouble for me with nose
anyway--whenever the test module
On Mon, Jun 9, 2008 at 10:43 AM, Andrew Straw [EMAIL PROTECTED] wrote:
I'm using it in some of my code, but I'll happily switch to nose. It
will make my life easier, however, if I can see how you've converted it.
If you do this, can you indicate what svn revision made the switch?
Certainly,
On Mon, Jun 9, 2008 at 10:47 AM, Matthew Brett [EMAIL PROTECTED] wrote:
I am sure you know this already, but you can just replace the tests
using ParametricTestCase with a nose test generator.
Thanks for pointing that out; it's a rather cool feature. :)
On Mon, Jun 9, 2008 at 12:16 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Only Windows_xp_64 still functions, but for how long? We need your help!
What version of the MS compilers is needed for a Windows build? I've
got a WinXP machine that could be used as a buildbot as long as I
don't have
That fixes it, thanks! Apparently I forgot the -U when I tried to
update numscons via easy_install yesterday. ;)
On Sun, Jun 8, 2008 at 2:11 AM, David Cournapeau
[EMAIL PROTECTED] wrote:
Alan McIntyre wrote:
I just updated my NumPy tree from svn trunk, and the SCons install now
fails
Hi all,
Later this week (after finals are done ;) I'll be checking in some
changes to switch NumPy tests over to nose, and I just wanted to give
the list a heads up and see if there's any concerns, etc.
On Mon, Jun 2, 2008 at 11:04 PM, Pierre GM [EMAIL PROTECTED] wrote:
* is there a way to
On Sun, Jun 8, 2008 at 6:49 PM, Nathan Bell [EMAIL PROTECTED] wrote:
On Sun, Jun 8, 2008 at 6:15 AM, Alan McIntyre [EMAIL PROTECTED] wrote:
Right now there's if __name__ == '__main__' boilerplate at the end
of every test module; nose can find and run tests without that being
there. I wanted
I just updated my NumPy tree from svn trunk, and the SCons install now
fails with the following message:
ImportError: Error importing numpy: you should not try to import numpy from
its source directory; please exit the numpy source tree, and relaunch
your python intepreter from
Here's an automatically generated list from the current numpy trunk.
I should really post the script I used to make this somewhere.
Anybody have any suggestions on a good place to put it?
On Fri, Jun 6, 2008 at 3:54 PM, Pierre GM [EMAIL PROTECTED] wrote:
Folks,
Where could I find a list of the
On Fri, Jun 6, 2008 at 4:50 PM, Keith Goodman [EMAIL PROTECTED] wrote:
On Fri, Jun 6, 2008 at 1:41 PM, Alan McIntyre [EMAIL PROTECTED] wrote:
Here's an automatically generated list from the current numpy trunk.
I should really post the script I used to make this somewhere.
Anybody have any
On Thu, Jun 5, 2008 at 10:16 PM, Keith Goodman [EMAIL PROTECTED] wrote:
How can that lead to instability? If the last half-million values are
small then they won't have a big impact on the mean even if they are
ignored. The variance is a mean too (of the squares), so it should be
stable too.
David,
We're in the process of switching to nose
(http://www.somethingaboutorange.com/mrl/projects/nose/) as the test
framework for 1.2; I'll try to keep an eye on stuff like that and make
it work properly if I can.
Alan
On Mon, Jun 2, 2008 at 11:20 AM, David Huard [EMAIL PROTECTED] wrote:
Hi,
Bala,
One thing I can think of is that you might have multiple versions of
Python installed. For example, I have Python 2.4 and 2.5 on my
machine, but numpy is only installed for 2.5. Since just running
python brings up 2.4, sometimes I find myself in the wrong
interpreter typing import numpy,
On Wed, May 28, 2008 at 1:37 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I think the bug is not raising an error on shape mismatch, the assumption on
the first index follows from that. For the out=x parameter, I propose the
rules:
1) x must have the shape of the expected output (1D in this
On Wed, May 28, 2008 at 5:10 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
Yes, we have mechanisms in place to do that. I haven't merged for a
while, because I am hoping that we can move the docstrings over to the
new (web application) system soon. If that doesn't happen, I will
probably
On Wed, May 28, 2008 at 3:34 PM, Charles R Harris I wonder if this
is something that ought to be looked at for all
functions with an out parameter? ndarray.compress also had problems
with array type mismatch (#789); I can't imagine that it's safe to
assume only these two functions were doing
On Wed, May 28, 2008 at 7:26 PM, Anne Archibald
[EMAIL PROTECTED] wrote:
One noticeable absence is all the ufuncs. (Partly this is because it's
not actually called out, or on fact anything at all; it's just the
last parameter if there are enough.) You might also check things like
objects
On Wed, May 21, 2008 at 11:35 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
On Wed, May 21, 2008 at 9:28 AM, Pierre GM [EMAIL PROTECTED] wrote:
The problem looks quite recent, and not related to numpy.ma itself: what
changed recently in the .tolist() method of ndarrays ? Why do we get these
On Wed, May 21, 2008 at 11:56 AM, Pierre GM [EMAIL PROTECTED] wrote:
On Wednesday 21 May 2008 11:39:32 Alan McIntyre wrote:
There's some commentary and a patch on NumPy ticket 793 on this issue:
http://scipy.org/scipy/numpy/ticket/793
OK, thanks a lot ! That's a C problem, then...
It's
On Mon, May 12, 2008 at 3:09 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
The much more important issue is
having the C extensions tested, and if anyone can figure out a way to
get gcov to generate those coverage reports, I'd be in the seventh
heaven. Thus far, the only way I know of
On Sun, May 11, 2008 at 2:04 PM, Anne Archibald
[EMAIL PROTECTED] wrote:
Also, is there a way to take a python function and automatically make
a ufunc out of it? (No, vectorize doesn't implement reduce(),
accumulate(), reduceat(), or outer().)
I've not used it, but have a look at
On Sat, May 10, 2008 at 11:14 AM, Keith Goodman [EMAIL PROTECTED] wrote:
Shouldn't a deprecation warning explain what the future behavior will
be? Is there a firm consensus on what that behavior will be?
For what the opinion of an interested observer is worth: I honestly
can't tell whether
101 - 122 of 122 matches
Mail list logo
