Testing if this gets posted... Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi all,
so I have been thinking about this a little more, and I do not think
there is a truly nice solution to the python bug:
http://bugs.python.org/issue4180 (does not create problems for new
pythons).
However, I have been so annoyed by trying to test FutureWarnings or
DeprecationWarnings in th
This would be an email.
--
Chip Parker
DevOps Engineer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Let's see if the instructions enclosed in
http://www.jamesh.id.au/articles/mailman-spamassassin/ which was
written in 2003 are still biting us.
--
Chip Parker
DevOps Engineer
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scip
Pandas has for quite a while has a travis build where we install numpy
master and then run our test suite.
e.g. here: https://travis-ci.org/pydata/pandas/jobs/77256007
Over the last year this has uncovered a couple of changes which affected
pandas (mainly using something deprecated which was turn
Hi,
On Wed, Aug 26, 2015 at 7:59 AM, Nathaniel Smith wrote:
> [Popping this off to its own thread to try and keep things easier to follow]
>
> On Tue, Aug 25, 2015 at 9:52 AM, Nathan Goldbaum
> wrote:
>>> - Lament: it would be really nice if we could get more people to
>>> test our beta r
As a Matplotlib developer I try to test our code manually with all betas
and rc of new numpy versions.
(And already pushed fixed a few new deprecation warnings with 1.10beta1
which otherwise passes our test suite.
I forgot to report this back since there were no issues to report )
However, we could
[Popping this off to its own thread to try and keep things easier to follow]
On Tue, Aug 25, 2015 at 9:52 AM, Nathan Goldbaum wrote:
>> - Lament: it would be really nice if we could get more people to
>> test our beta releases, because in practice right now 1.x.0 ends
>> up being where
Hi Colin.
this is an interesting test with different hardware.
As a summary:
- Python-2.7 amd64
- numpy-0.1.9.openblas: OK
- scipy-0.15.1.openblas:2 errors 11 failures
- CPU: AMD A8-5600K APU (piledriver)
scipy errors and failures due to piledriver:
(1) ERROR: test_improvement (test_qua
Since I am trying to add a "printoptions" context manager, I would like to
test it. Should I add tests, or can I somehow use it from an ipython shell?
On Sun, Oct 27, 2013 at 7:12 PM, Charles R Harris wrote:
>
>
>
> On Sun, Oct 27, 2013 at 4:59 PM, Neil Girdhar wrote:
>
>> How do I test a patc
Ah, sorry, didn't see that I can do that from runtests!! Thanks!!
On Sun, Oct 27, 2013 at 7:13 PM, Neil Girdhar wrote:
> Since I am trying to add a "printoptions" context manager, I would like to
> test it. Should I add tests, or can I somehow use it from an ipython shell?
>
>
> On Sun, Oct 2
On Sun, Oct 27, 2013 at 4:59 PM, Neil Girdhar wrote:
> How do I test a patch that I've made locally? I can't seem to import
> numpy locally:
>
> Error importing numpy: you should not try to import numpy from
> its source directory; please exit the numpy source tree, and
> relaunch
>
On Sun, Oct 27, 2013 at 10:59 PM, Neil Girdhar wrote:
> How do I test a patch that I've made locally? I can't seem to import numpy
> locally:
>
> Error importing numpy: you should not try to import numpy from
> its source directory; please exit the numpy source tree, and
> relaunch
>
How do I test a patch that I've made locally? I can't seem to import numpy
locally:
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 there.
_
On 11/8/12 7:55 PM, Dag Sverre Seljebotn wrote:
> On 11/08/2012 06:59 PM, Francesc Alted wrote:
>> On 11/8/12 6:38 PM, Dag Sverre Seljebotn wrote:
>>> On 11/08/2012 06:06 PM, Francesc Alted wrote:
On 11/8/12 1:41 PM, Dag Sverre Seljebotn wrote:
> On 11/07/2012 08:41 PM, Neal Becker wrote:
On 11/08/2012 07:55 PM, Dag Sverre Seljebotn wrote:
> On 11/08/2012 06:59 PM, Francesc Alted wrote:
>> On 11/8/12 6:38 PM, Dag Sverre Seljebotn wrote:
>>> On 11/08/2012 06:06 PM, Francesc Alted wrote:
On 11/8/12 1:41 PM, Dag Sverre Seljebotn wrote:
> On 11/07/2012 08:41 PM, Neal Becker wro
On 11/08/2012 06:59 PM, Francesc Alted wrote:
> On 11/8/12 6:38 PM, Dag Sverre Seljebotn wrote:
>> On 11/08/2012 06:06 PM, Francesc Alted wrote:
>>> On 11/8/12 1:41 PM, Dag Sverre Seljebotn wrote:
On 11/07/2012 08:41 PM, Neal Becker wrote:
> Would you expect numexpr without MKL to give a s
On 11/8/12 6:38 PM, Dag Sverre Seljebotn wrote:
> On 11/08/2012 06:06 PM, Francesc Alted wrote:
>> On 11/8/12 1:41 PM, Dag Sverre Seljebotn wrote:
>>> On 11/07/2012 08:41 PM, Neal Becker wrote:
Would you expect numexpr without MKL to give a significant boost?
>>> If you need higher performance
On 11/08/2012 06:06 PM, Francesc Alted wrote:
> On 11/8/12 1:41 PM, Dag Sverre Seljebotn wrote:
>> On 11/07/2012 08:41 PM, Neal Becker wrote:
>>> Would you expect numexpr without MKL to give a significant boost?
>> If you need higher performance than what numexpr can give without using
>> MKL, you
On 11/8/12 1:41 PM, Dag Sverre Seljebotn wrote:
> On 11/07/2012 08:41 PM, Neal Becker wrote:
>> Would you expect numexpr without MKL to give a significant boost?
> If you need higher performance than what numexpr can give without using
> MKL, you could look at code such as this:
>
> https://github.
On Thu, Nov 8, 2012 at 2:22 AM, Francesc Alted wrote:
>> -- It can remove a lot of uneccessary temporary creation.
> Well, the temporaries are still created, but the thing is that, by
> working with small blocks at a time, these temporaries fit in CPU cache,
> preventing copies into main memor
On 11/07/2012 08:41 PM, Neal Becker wrote:
> Would you expect numexpr without MKL to give a significant boost?
If you need higher performance than what numexpr can give without using
MKL, you could look at code such as this:
https://github.com/herumi/fmath/blob/master/fmath.hpp#L480
But that me
On 11/8/12 12:35 AM, Chris Barker wrote:
> On Wed, Nov 7, 2012 at 11:41 AM, Neal Becker wrote:
>> Would you expect numexpr without MKL to give a significant boost?
> It can, depending on the use case:
> -- It can remove a lot of uneccessary temporary creation.
> -- IIUC, it works on blocks of
On 11/7/12 8:41 PM, Neal Becker wrote:
> Would you expect numexpr without MKL to give a significant boost?
Yes. Have a look at how numexpr's own multi-threaded virtual machine
compares with numexpr using VML:
http://code.google.com/p/numexpr/wiki/NumexprVML
As it can be seen, the best results
On Wed, Nov 7, 2012 at 11:41 AM, Neal Becker wrote:
> Would you expect numexpr without MKL to give a significant boost?
It can, depending on the use case:
-- It can remove a lot of uneccessary temporary creation.
-- IIUC, it works on blocks of data at a time, and thus can keep
things in cache m
Would you expect numexpr without MKL to give a significant boost?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 11/07/2012 03:30 PM, Neal Becker wrote:
> David Cournapeau wrote:
>
>> On Wed, Nov 7, 2012 at 1:56 PM, Neal Becker wrote:
>>> David Cournapeau wrote:
>>>
On Wed, Nov 7, 2012 at 12:35 PM, Neal Becker wrote:
> I'm trying to do a bit of benchmarking to see if amd libm/acml will help
David Cournapeau wrote:
> On Wed, Nov 7, 2012 at 1:56 PM, Neal Becker wrote:
>> David Cournapeau wrote:
>>
>>> On Wed, Nov 7, 2012 at 12:35 PM, Neal Becker wrote:
I'm trying to do a bit of benchmarking to see if amd libm/acml will help
me.
I got an idea that instead of buildi
David Cournapeau wrote:
> On Wed, Nov 7, 2012 at 1:56 PM, Neal Becker wrote:
>> David Cournapeau wrote:
>>
>>> On Wed, Nov 7, 2012 at 12:35 PM, Neal Becker wrote:
I'm trying to do a bit of benchmarking to see if amd libm/acml will help
me.
I got an idea that instead of buildi
On Wed, Nov 7, 2012 at 1:56 PM, Neal Becker wrote:
> David Cournapeau wrote:
>
>> On Wed, Nov 7, 2012 at 12:35 PM, Neal Becker wrote:
>>> I'm trying to do a bit of benchmarking to see if amd libm/acml will help me.
>>>
>>> I got an idea that instead of building all of numpy/scipy and all of my
>>
David Cournapeau wrote:
> On Wed, Nov 7, 2012 at 12:35 PM, Neal Becker wrote:
>> I'm trying to do a bit of benchmarking to see if amd libm/acml will help me.
>>
>> I got an idea that instead of building all of numpy/scipy and all of my
>> custom modules against these libraries, I could simply use
On Wed, Nov 7, 2012 at 12:35 PM, Neal Becker wrote:
> I'm trying to do a bit of benchmarking to see if amd libm/acml will help me.
>
> I got an idea that instead of building all of numpy/scipy and all of my custom
> modules against these libraries, I could simply use:
>
> LD_PRELOAD=/opt/amdlibm-3
I'm trying to do a bit of benchmarking to see if amd libm/acml will help me.
I got an idea that instead of building all of numpy/scipy and all of my custom
modules against these libraries, I could simply use:
LD_PRELOAD=/opt/amdlibm-3.0.2/lib/dynamic/libamdlibm.so:/opt/acml5.2.0/gfortran64/lib/l
18.12.2011 00:49, Soeren Sonnenburg kirjoitti:
[clip]
> I've looked at the source code of numpy 1.6.1 and couldn't find the
> respective code... I guess I must be doing something wrong but there
> really was no call to PyObject_CheckBuffer() ...
Look for PyObject_GetBuffer
> The problem is I don'
On Sat, 2011-12-17 at 15:29 +0100, Pauli Virtanen wrote:
> 17.12.2011 09:42, Soeren Sonnenburg kirjoitti:
> > Doesn't work, complaining that the object has no __buffer__ attribute.
> >
> > Digging into the numpy c code it seems numpy doesn't even support the
> > buffer protocol but only the depreca
17.12.2011 09:42, Soeren Sonnenburg kirjoitti:
> Doesn't work, complaining that the object has no __buffer__ attribute.
>
> Digging into the numpy c code it seems numpy doesn't even support the
> buffer protocol but only the deprecated (old) one
> http://docs.python.org/c-api/objbuffer.html .
[clip
What version of numpy are you using? IIRC the new buffer protocol has
been supported since numpy 1.5.
On 17 December 2011 08:42, Soeren Sonnenburg wrote:
> Doesn't work, complaining that the object has no __buffer__ attribute.
>
> Digging into the numpy c code it seems numpy doesn't even support
Doesn't work, complaining that the object has no __buffer__ attribute.
Digging into the numpy c code it seems numpy doesn't even support the
buffer protocol but only the deprecated (old) one
http://docs.python.org/c-api/objbuffer.html .
At least there is nowhere a PyObject_CheckBuffer() call but
What happens if you use
y=numpy.frombuffer(x) ?
//Torgil
On Sat, Dec 17, 2011 at 1:41 AM, Soeren Sonnenburg wrote:
> Hi,
>
> I've implemented the buffer protocol
> (http://www.python.org/dev/peps/pep-3118/) for some matrix class and
> when I manually call PyObject_GetBuffer on that object I se
Hi,
I've implemented the buffer protocol
(http://www.python.org/dev/peps/pep-3118/) for some matrix class and
when I manually call PyObject_GetBuffer on that object I see that I get
the right matrix.
Now I'd like to see numpy use the buffer protocol of my class. Does
anyone know how to test that?
On Sat, Feb 27, 2010 at 3:43 PM, Ralf Gommers
wrote:
>
> Yes that is clear. Would it make sense to first release scipy 0.7.2 though?
> Then numpy 1.4.1 can be tested against it and we can be sure it works. The
> other way around it's not possible to test.
Yes it is, you just have to build scipy
On Sat, Feb 27, 2010 at 2:33 PM, David Cournapeau wrote:
>
> Sorry, I should have been clearer in the above quoted list. There were
> two issues with numpy 1.4.0, one caused by datetime, and one caused by
> other changes to growing structures. The second one is ok for most
> cases, but cython < 0.
On Sat, Feb 27, 2010 at 11:59 AM, Ralf Gommers
wrote:
>
>
> So here is how I see things in the near future for release:
> - compile a simple binary installer for mac os x and windows (no need
> for doc or multiple archs) from 1.4.x
> - test this with the scipy binary out there (running the full
On Sat, Feb 27, 2010 at 8:17 AM, David Cournapeau wrote:
> On Sat, Feb 27, 2010 at 2:44 AM, wrote:
>
> >
> > I think I mixed up some things then,
> > scipy 0.7.1 cython files should be regenerated with the latest cython
> > release so that it doesn't check the sizeof anymore.
> > Then, a scipy 0
On Sat, Feb 27, 2010 at 2:44 AM, wrote:
>
> I think I mixed up some things then,
> scipy 0.7.1 cython files should be regenerated with the latest cython
> release so that it doesn't check the sizeof anymore.
> Then, a scipy 0.7.1 build against numpy 1.3 would also work without
> recompiling agai
On Fri, Feb 26, 2010 at 11:26 AM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Fri, Feb 26, 2010 at 10:53 AM, wrote:
>
>> On Fri, Feb 26, 2010 at 12:50 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Fri, Feb 26, 2010 at 10:44 AM, wrote:
>> >>
>> >> On Fri, Feb 26, 2010 at 12:
On Fri, Feb 26, 2010 at 10:53 AM, wrote:
> On Fri, Feb 26, 2010 at 12:50 PM, Charles R Harris
> wrote:
> >
> >
> > On Fri, Feb 26, 2010 at 10:44 AM, wrote:
> >>
> >> On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
> >> wrote:
> >> >
> >> >
> >> > On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virt
On Fri, Feb 26, 2010 at 12:50 PM, Charles R Harris
wrote:
>
>
> On Fri, Feb 26, 2010 at 10:44 AM, wrote:
>>
>> On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
>> >>
>> >> pe, 2010-02-26 kello 12:26 -0500, josef.
On Fri, Feb 26, 2010 at 10:44 AM, wrote:
> On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
> wrote:
> >
> >
> > On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
> >>
> >> pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
> >> [clip]
> >> > recompiling wouldn't be enoug
On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
wrote:
>
>
> On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
>>
>> pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
>> [clip]
>> > recompiling wouldn't be enough, the cython c files also need to be
>> > regenerated for a
On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
> pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
> [clip]
> > recompiling wouldn't be enough, the cython c files also need to be
> > regenerated for a different numpy version.
> > (If I understand the problem correctly.)
>
pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
[clip]
> recompiling wouldn't be enough, the cython c files also need to be
> regenerated for a different numpy version.
> (If I understand the problem correctly.)
No. The Cython-generated sources just use sizeof(PyArray_Descr), the
On Fri, Feb 26, 2010 at 12:19 PM, Pauli Virtanen wrote:
> pe, 2010-02-26 kello 12:09 -0500, josef.p...@gmail.com kirjoitti:
>> On Fri, Feb 26, 2010 at 12:00 PM, Ralf Gommers
> [clip]
>> > ValueError: numpy.dtype does not appear to be the correct type object
>>
>> This looks like the cython type ch
pe, 2010-02-26 kello 12:09 -0500, josef.p...@gmail.com kirjoitti:
> On Fri, Feb 26, 2010 at 12:00 PM, Ralf Gommers
[clip]
> > ValueError: numpy.dtype does not appear to be the correct type object
>
> This looks like the cython type check problem, ckdtree.c doesn't look
> compatible with your nump
On Fri, Feb 26, 2010 at 12:00 PM, Ralf Gommers
wrote:
> Hi,
>
> I built an installer for OS X and did some testing on a clean computer. All
> NumPy tests pass. SciPy (0.7.1 binary) gives a number of errors and
> failures, I copied one of each type below. For full output see
> http://pastebin.com/e
Hi,
I built an installer for OS X and did some testing on a clean computer. All
NumPy tests pass. SciPy (0.7.1 binary) gives a number of errors and
failures, I copied one of each type below. For full output see
http://pastebin.com/eEcwkzKr . To me it looks like the failures are
harmless, and the k
On Mon, Jan 19, 2009 at 11:26 PM, Robert Kern wrote:
> On Tue, Jan 20, 2009 at 00:21, Charles R Harris
> wrote:
> >
> > On Mon, Jan 19, 2009 at 10:48 PM, Robert Kern
> wrote:
> >>
> >> On Mon, Jan 19, 2009 at 23:36, Charles R Harris
> >> wrote:
> >> >
> >> > On Mon, Jan 19, 2009 at 9:17 PM, Ro
On Tue, Jan 20, 2009 at 00:21, Charles R Harris
wrote:
>
> On Mon, Jan 19, 2009 at 10:48 PM, Robert Kern wrote:
>>
>> On Mon, Jan 19, 2009 at 23:36, Charles R Harris
>> wrote:
>> >
>> > On Mon, Jan 19, 2009 at 9:17 PM, Robert Kern
>> > wrote:
>> >>
>> >> On Mon, Jan 19, 2009 at 22:09, Charles R
On Mon, Jan 19, 2009 at 10:48 PM, Robert Kern wrote:
> On Mon, Jan 19, 2009 at 23:36, Charles R Harris
> wrote:
> >
> > On Mon, Jan 19, 2009 at 9:17 PM, Robert Kern
> wrote:
> >>
> >> On Mon, Jan 19, 2009 at 22:09, Charles R Harris
> >> wrote:
> >> >
> >> >
> >> > On Mon, Jan 19, 2009 at 7:23
On Mon, Jan 19, 2009 at 23:36, Charles R Harris
wrote:
>
> On Mon, Jan 19, 2009 at 9:17 PM, Robert Kern wrote:
>>
>> On Mon, Jan 19, 2009 at 22:09, Charles R Harris
>> wrote:
>> >
>> >
>> > On Mon, Jan 19, 2009 at 7:23 PM, Jonathan Taylor
>> > wrote:
>> >>
>> >> Interesting. That makes sense a
On Mon, Jan 19, 2009 at 9:17 PM, Robert Kern wrote:
> On Mon, Jan 19, 2009 at 22:09, Charles R Harris
> wrote:
> >
> >
> > On Mon, Jan 19, 2009 at 7:23 PM, Jonathan Taylor
> > wrote:
> >>
> >> Interesting. That makes sense and I suppose that also explains why
> >> there is no function to do th
On Mon, Jan 19, 2009 at 22:09, Charles R Harris
wrote:
>
>
> On Mon, Jan 19, 2009 at 7:23 PM, Jonathan Taylor
> wrote:
>>
>> Interesting. That makes sense and I suppose that also explains why
>> there is no function to do this sort of thing for you.
>
> A combination of relative and absolute err
On Mon, Jan 19, 2009 at 7:23 PM, Jonathan Taylor <
jonathan.tay...@utoronto.ca> wrote:
> Interesting. That makes sense and I suppose that also explains why
> there is no function to do this sort of thing for you.
>
A combination of relative and absolute errors is another common solution,
i.e., t
Interesting. That makes sense and I suppose that also explains why
there is no function to do this sort of thing for you.
Jon.
On Mon, Jan 19, 2009 at 3:55 PM, Robert Kern wrote:
> On Mon, Jan 19, 2009 at 14:43, Jonathan Taylor
> wrote:
>> Hi,
>>
>> When solving a quadratic equation I get that
On Mon, Jan 19, 2009 at 14:43, Jonathan Taylor
wrote:
> Hi,
>
> When solving a quadratic equation I get that alpha =
> -3.78336776728e-31 which I believe to be far below machine precision:
>
> finfo(float).eps
> 2.2204460492503131e-16
>
> But an if statement like:
>
> if alpha == 0:
> ...
>
> do
Hi,
When solving a quadratic equation I get that alpha =
-3.78336776728e-31 which I believe to be far below machine precision:
finfo(float).eps
2.2204460492503131e-16
But an if statement like:
if alpha == 0:
...
does not catch this. Is there a better way to check for things that
are essent
On Sun, Jul 20, 2008 at 11:34 PM, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> For the rest I can't figure out how to get the information. I suspect we
> can standardise on things around six month old. Debian unstable tracks
> closely upstream, Ubuntu and Fedora have a release cycle of 6 months, I
>
On Sun, Jul 20, 2008 at 11:19:57PM -0400, Alan McIntyre wrote:
> On Sun, Jul 20, 2008 at 11:17 PM, Gael Varoquaux
> <[EMAIL PROTECTED]> wrote:
> > There might be a case to move to 10.3, considering the large amount of
> > bug fixes, but in general I think it is a bad idea to require leading
> > edg
On Sun, Jul 20, 2008 at 11:17 PM, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> There might be a case to move to 10.3, considering the large amount of
> bug fixes, but in general I think it is a bad idea to require leading
> edge packages. The reason being that you would like people to be able to
> r
On Sun, Jul 20, 2008 at 11:09:04PM -0400, Alan McIntyre wrote:
> Actually I was considering asking to move the minimum nose version up
> to 0.10.3 just because it's the current version before this aesthetic
> issue came up. There's about 30 bug fixes between 0.10.0 and 0.10.3,
> including one that
On Sun, Jul 20, 2008 at 10:56 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> I don't think aesthetics are worth requiring a particular version.
> numpy doesn't need it; the users can decide whether they want it or
> not. We should try to have it installed on the buildbots, though,
> since we *are* th
On Sun, Jul 20, 2008 at 21:47, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 20, 2008 at 9:17 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote:
>> The skipped test verbosity is annoying; I'll see if there's a way to
>> make that a bit cleaner-looking for some low verbosity level.
>
> The latest
On Sun, Jul 20, 2008 at 9:17 PM, Alan McIntyre <[EMAIL PROTECTED]> wrote:
> The skipped test verbosity is annoying; I'll see if there's a way to
> make that a bit cleaner-looking for some low verbosity level.
The latest release version of nose from easy_install (0.10.3) doesn't
generate that verbo
On Sun, Jul 20, 2008 at 7:10 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> Not raising errors seems ok for examples, but some of the unit tests are
> also implemented as doctests and the failures are hidden in the logs. I'm
> not sure what to do about this, but thought it worth pointing out. Al
Alan, Stefan
Not raising errors seems ok for examples, but some of the unit tests are
also implemented as doctests and the failures are hidden in the logs. I'm
not sure what to do about this, but thought it worth pointing out. Also, it
would be nice if skipped tests didn't generate large bits of p
On Thu, Jul 17, 2008 at 4:25 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> I was trying to reuse your #random checker for ipython but kept
> running into problems. Is it working for you in numpy in actual code?
> Because in the entire SVN tree I only see it mentioned here:
>
> maqroll[numpy]> g
Hi Alan,
I was trying to reuse your #random checker for ipython but kept
running into problems. Is it working for you in numpy in actual code?
Because in the entire SVN tree I only see it mentioned here:
maqroll[numpy]> grin #random
./numpy/testing/nosetester.py:
43 : if
77 matches
Mail list logo
