On Mon, Nov 16, 2009 at 11:07 PM, Chris fonnesb...@gmail.com wrote:
I'm pretty sure this shouldn't happen:
In [1]: from numpy import min
In [2]: min(5000, 4)
Out[2]: 5000
The way you're calling it is working like this: min((5000,) , axis=4)
so you'd need to do this instead: min((5000,4))
On Mon, Nov 16, 2009 at 11:34 PM, V. Armando Solé s...@esrf.fr wrote:
Sebastian Berg wrote:
Known issue, I think someone posted about it a while ago too. The numpy
min is array aware, and it expects an array. The second argument is the
axis, which in the case of a single number doesn't matter.
On Wed, Mar 17, 2010 at 8:51 AM, gerardob gberbeg...@gmail.com wrote:
How can i modified all the values of a numpy array whose value is smaller
than a given epsilon to zero?
Example
epsilon=0.01
a = [[0.003,2][23,0.0001]]
output:
[[0,2][23,0]]
Give this a try:
import numpy as np
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
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 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 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 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
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,
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,
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.
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
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
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
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
On Wed, Jun 11, 2008 at 6:09 PM, Robert Kern [EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 04:57, Stéfan van der Walt [EMAIL PROTECTED] wrote:
2008/6/10 Alan McIntyre [EMAIL PROTECTED]:
Is the stuff Robert pointed out on a wiki page somewhere? It would be
nice to have a Welcome noob NumPy
Hi all,
I just checked in the switch to use nose to run unit tests. Please
let me know if you experience any difficulties as a result.
Thanks,
Alan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
On Mon, Jun 16, 2008 at 8:39 PM, Robert Kern [EMAIL PROTECTED] wrote:
On Mon, Jun 16, 2008 at 19:28, Alan McIntyre [EMAIL PROTECTED] wrote:
Please port over the changes I made to scipy.testing in scipy's r4424
in order to avoid importing nose until the actual execution of tests.
Done in r5289
On Mon, Jun 16, 2008 at 9:04 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Did you add any documentation to the readme? Any particular version
dependency for Nose?
I did update README.txt, but I forgot to put the minimum Nose version
in there; thanks for mentioning that. I just checked in an
To whomever knows,
Where do we keep the buildbot configuration? The arguments for
numpy.test have changed with the switch to nose, so the test step
fails. It also appears nose needs to be installed/updated on the
build slaves.
Thanks,
Alan
___
On Mon, Jun 16, 2008 at 11:17 PM, Robert Kern [EMAIL PROTECTED] wrote:
These files were for the in-development g3 version of f2py. That
development has moved outside of numpy, so I think they can be removed
wholesale. Some of them seem to require a Fortran 90 compiler, so I
have had them fail
On Tue, Jun 17, 2008 at 9:26 AM, David Huard [EMAIL PROTECTED] wrote:
I noticed that NumpyTest and NumpyTestCase disappeared, and now I am
wondering whether these classes part of the public interface or were they
reserved for internal usage ?
In the former, it might be well to deprecate them
On Tue, Jun 17, 2008 at 8:15 PM, Anne Archibald
[EMAIL PROTECTED] wrote:
Uh, I assumed NumpyTestCase was public and used it. I'm presumably not
alone, so perhaps a deprecation warning would be good. What
backward-compatible class should I use? unittest.TestCase?
Yes, unittest.TestCase seemed
On Mon, Jun 16, 2008 at 8:39 PM, Robert Kern [EMAIL PROTECTED] wrote:
Please port over the changes I made to scipy.testing in scipy's r4424
in order to avoid importing nose until the actual execution of tests.
By the way, I notice that making those changes broke the ability to
run a single test
On Wed, Jun 18, 2008 at 12:21 PM, Christopher Hanley [EMAIL PROTECTED] wrote:
I have received the following message from our system guru here at STScI
regarding the recent changes to the way testing is done with nose. The
automated scripts he was using to monitor the success or failure of
On Wed, Jun 18, 2008 at 11:42 AM, Anne Archibald
[EMAIL PROTECTED] wrote:
You can replace ParametricTest with generators, as described here:
http://scipy.org/scipy/scipy/wiki/TestingGuidelines
Hmm. This won't work with the current version of numpy, will it? That
is, it needs nose. (I run
On Tue, Jun 17, 2008 at 7:38 AM, Alan McIntyre [EMAIL PROTECTED] wrote:
Where do we keep the buildbot configuration? The arguments for
numpy.test have changed with the switch to nose, so the test step
fails. It also appears nose needs to be installed/updated on the
build slaves.
Eh, please
On Wed, Jun 18, 2008 at 12:05 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
a) Warn that Nose is becoming a dependency (next release).
Is next release referring to 1.2 or the release after that? If it's
the release after 1.2, then I assume that 1.2 must still be able to
run all its tests
On Wed, Jun 18, 2008 at 5:24 PM, Robert Kern [EMAIL PROTECTED] wrote:
- The signature of numpy.test in 1.2 will be backward compatible with
1.1, and it will at least return some indication of failure (if not
the same object as in 1.1). This will, by the way, make it different
from the
Hi all,
Just wanted to get feedback about the following changes before I make
them. Please speak up if any of this seems objectionable to you.
- The old test framework classes will be restored, but will not be
used anywhere in NumPy's tests. If your old tests still don't work
with the restored
Hi all,
Nose has a plugin (included in the current version of nose) that uses
Ned Batchelder's coverage module
(http://nedbatchelder.com/code/modules/coverage.html) to provide
coverage information. Is it acceptable to use this capability in nose
to provide coverage reporting for NumPy? The
On Fri, Jun 20, 2008 at 5:44 PM, Robert Kern [EMAIL PROTECTED] wrote:
Specifically, what changes are you thinking of making?
numpy.test(coverage=True) already triggers nose's coverage feature.
Actually, that wasn't supposed to get added in my last checkin; I was
experimenting with it and forgot
On Fri, Jun 20, 2008 at 5:35 PM, Robert Kern [EMAIL PROTECTED] wrote:
So NoseTester.run() basically just calls nose.run(). That basically
just instantiates nose.core.TestProgram and returns the .success
attribute of it. Unfortunately, the TextTestResults object (a nose
subclass of
On Fri, Jun 20, 2008 at 7:22 PM, Fernando Perez [EMAIL PROTECTED] wrote:
It may be worth bringing it up wtih the nose guys here:
http://lists.idyll.org/listinfo/testing-in-python
The nose author seems very responsive, and Titus Brown is on the list
and cares a lot about numpy/scipy, and he
It looks like the Windows_XP_x86_64_MSVC buildbot is stuck in the
build phase for some reason.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
, 2008 at 5:01 PM, Alan McIntyre [EMAIL PROTECTED] wrote:
Hi all,
Just wanted to get feedback about the following changes before I make
them. Please speak up if any of this seems objectionable to you.
- The old test framework classes will be restored, but will not be
used anywhere in NumPy's
For what it's worth, I tried deleting scipy/testing, changed all the
scipy.testing references to numpy.testing, and it would appear that
the NumPy test setup is able to run all the SciPy tests just fine
(which shouldn't be too surprising, since that's where I stole it from
in the first place). So
On Mon, Jun 23, 2008 at 2:02 PM, Fernando Perez [EMAIL PROTECTED] wrote:
There's also the option of marking them so doctest skips them via
#doctest: +SKIP
http://docs.python.org/lib/doctest-options.html
For short examples, that seems like a good option, but it seems like
you have to have
On Mon, Jun 23, 2008 at 2:37 PM, Pauli Virtanen [EMAIL PROTECTED] wrote:
Can you make the convention chosen for the examples (currently only in
the doc wiki, not yet in SVN) to work: assuming import numpy as np in
examples?
This would remove the need for those from numpy import * lines in the
On Mon, Jun 23, 2008 at 3:21 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
Another alternative is to replace +SKIP with something like +IGNORE.
That way, the statement is still executed, we just don't care about
its outcome. If we skip the line entirely, it often affects the rest
of the
On Mon, Jun 23, 2008 at 3:57 PM, Pauli Virtanen [EMAIL PROTECTED] wrote:
Schematic code (such as that currently in numpy.bmat) that doesn't run
probably shouldn't be written with , and for it the ReST block quote
syntax is also looks OK.
But I'm personally not in favor of a distinction
On Mon, Jun 23, 2008 at 4:07 PM, Pauli Virtanen [EMAIL PROTECTED] wrote:
Another idea (in addition to whitelisting): how easy would it be to
subclass doctest.DocTestParser so that it would eg. automatically +IGNORE
any doctest lines containing plt.?
I'll play around with that and see how hard
On Mon, Jun 23, 2008 at 4:51 PM, Robert Kern [EMAIL PROTECTED] wrote:
I agree that this can be awkward sometimes, and should certainly not
be policy, but one can usually get around this. Instead of printing
the result, you can use it, or demonstrate porperties:
random_array =
On Mon, Jun 23, 2008 at 3:03 PM, Alan McIntyre [EMAIL PROTECTED] wrote:
On Mon, Jun 23, 2008 at 2:37 PM, Pauli Virtanen [EMAIL PROTECTED] wrote:
Can you make the convention chosen for the examples (currently only in
the doc wiki, not yet in SVN) to work: assuming import numpy as np in
examples
On Mon, Jun 23, 2008 at 2:37 PM, Pauli Virtanen [EMAIL PROTECTED] wrote:
Can you make the convention chosen for the examples (currently only in
the doc wiki, not yet in SVN) to work: assuming import numpy as np in
examples?
Are there any other implicit imports that we will need? How about for
On Thu, Jun 26, 2008 at 1:37 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Decorators weren't introduced until Python2.4. I'm not sure what version we
require now, that information should probably be added to a DEPENDENCY file,
or maybe the README. Anyway, if we still support Python2.3 we can't
On Thu, Jun 26, 2008 at 1:51 PM, Jarrod Millman [EMAIL PROTECTED] wrote:
Starting with NumPy 1.2 and SciPy 0.7 we will require Python 2.4 or
greater. I will make sure to update the documentation later today, if
no one gets to it before me.
In that case I will leave the decorators in
While I was working on the doctest tweaks, I ran across a doctest that
failed because tensorsolve uses a function wrap that's not defined.
It seems that I should make the following change to fix it (at the
start of tensorsolve's code) :
-a = asarray(a)
+a,wrap = _makearray(a)
Doing so
Hi all,
I can commit any/all of the following changes as long as they are
agreeable to everybody:
1. All doctests in NumPy will have the numpy module available in their
execution context as np.
2. Turn on the normalized whitespace option for all doctests. Having
a doctest fail just because
Hi all,
It seems to me that the buildbots should be running the doctests in
addition to the unit tests, but right now the buildbot test command
numpy.test(level=,verbosity=) doesn't do that. We could
either add doctests=True to the buildbot test command, or make
level above some
On Mon, Jun 30, 2008 at 2:55 PM, Robert Kern [EMAIL PROTECTED] wrote:
Add the doctests argument.
Where is the buildbot configuration kept?
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
On Mon, Jun 30, 2008 at 1:54 PM, Alan McIntyre [EMAIL PROTECTED] wrote:
1. All doctests in NumPy will have the numpy module available in their
execution context as np.
2. Turn on the normalized whitespace option for all doctests. Having
a doctest fail just because there's a space after your
Just a few questions/comments about doctests:
1. Should all doctests be written such that you could start Python, do
an import numpy as np, and then type in the examples verbatim? There
are a number that currently wouldn't work that way (they depend on the
function under test being in the local
Hi all,
This week I'm going to start working on new tests to improve Python
code coverage in NumPy (C code coverage will come later in the summer,
or maybe even after GSoC). Does anyone have recommendations for
particularly important bits of code that need coverage? If not, I'm
just going to
On Tue, Jul 1, 2008 at 2:45 PM, Robert Kern [EMAIL PROTECTED] wrote:
If the
auto-ignore capability is still needed after that, I'll work on it.
It seems to me that the ellipsis mechanism just allows the output to
differ. However, matplotlib would still be required because plt.plot()
would
On Tue, Jul 1, 2008 at 2:37 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I note that a lot of unit test files import tons of specific functions,
numpy.core, etc., etc. Is there any reason not to fix things up to
import numpy as np
from numpy.testing import *
I fixed one file this way, but
On Tue, Jul 1, 2008 at 3:20 PM, Robert Kern [EMAIL PROTECTED] wrote:
Can it work on an entire section? If not, can we do something that
works on a whole section? Everything after Plot the window and its
frequency response: is not required for testing.
It's on a per-line basis at the moment, so
On Tue, Jul 1, 2008 at 3:39 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
We could always just make the plotting section one of those it's just
an example not a doctest things and remove the (since it
doesn't appear to provide any useful test coverage or anything).
Would it serve to overload
On Tue, Jul 1, 2008 at 3:33 PM, Robert Kern [EMAIL PROTECTED] wrote:
That's not a bad idea. Coordinate with Stéfan about the details (if
any are left to be decided).
Ok, will do. I'll also update all the test documentation I can find
so that documenters have a chance of being aware of the
On Tue, Jul 1, 2008 at 3:37 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
A lot of the imports seem to have just grown over the years, some even
contain duplicates. So I think cleaning up would be a good idea if no one
objects.
Ok. As a pre-emptive clarification, I'll only be tweaking imports
On Tue, Jul 1, 2008 at 4:41 PM, Pauli Virtanen [EMAIL PROTECTED] wrote:
All in all, I'd estimate this to be ~100 lines, put in a suitable
location.
If possible, I'd like other possibilities be considered first before
jumping this route. I think it would be nice to retain the ability to run
Some test files have a set_local_path()/restore_path() pair at the
top, and some don't. Is there any reason to be changing sys.path like
this in the test modules? If not, I'll take them out when I see them.
Thanks,
Alan
___
Numpy-discussion mailing
On Wed, Jul 2, 2008 at 9:35 AM, Pearu Peterson [EMAIL PROTECTED] wrote:
Alan McIntyre wrote:
Some test files have a set_local_path()/restore_path() pair at the
top, and some don't. Is there any reason to be changing sys.path like
this in the test modules? If not, I'll take them out when I
On Wed, Jul 2, 2008 at 1:25 PM, Robert Kern [EMAIL PROTECTED] wrote:
Please remove them and adjust the imports. As I've mentioned before,
numpy and scipy can now reliably be built in-place with python
setup.py build_src --inplace build_ext --inplace. This is a more
robust method to test
On Wed, Jul 2, 2008 at 5:22 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
The Mac seems to have a whole different set of errors than the other bots,
lots of import errors like
ERROR: Failure: ImportError (cannot import name log)
I wonder if there is a path issue somewhere?
At least one of
On Wed, Jul 2, 2008 at 5:47 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
How about a slight modification to Fernando's idea: a dummy function that
a) Does nothing if matplotlib is not installed
b) Otherwise passes through calls to matplotlib, after setting the
backend to /dev/null. Any
On Thu, Jul 3, 2008 at 3:16 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
Sorry for the slow response, I'm still catching up.
I think if we turned on doctests right now, there would be about 100
test failures, so I've got plenty of my own catching up to do before
doctests really need to be
Just a couple of quick questions for whomever knows:
1. Should we skip the numpy/f2py directory when looking for doctests?
2. Are the functions in numpy/lib/convdtype.py used anywhere? I can
fix the doctests so they run, but I can't find anywhere they are used,
so I wanted to see if they were
On Thu, Jul 3, 2008 at 8:26 PM, Robert Kern [EMAIL PROTECTED] wrote:
1. Should we skip the numpy/f2py directory when looking for doctests?
I don't see anything there that should cause problems (according to my
understanding of the collector). Are you seeing problems?
Actually it's a problem
Since chararray doesn't currently have any tests, I'm writing some,
and I ran across a couple of things that didn't make sense to me:
1. The code for __mul__ is exactly the same as that for __rmul__; is
there any reason __rmul__ shouldn't just call __mul__?
1.5. __radd__ seems like it doesn't do
On Tue, Jul 8, 2008 at 1:29 PM, Travis E. Oliphant
[EMAIL PROTECTED] wrote:
Alan McIntyre wrote:
Since chararray doesn't currently have any tests, I'm writing some,
and I ran across a couple of things that didn't make sense to me:
1. The code for __mul__ is exactly the same
On Tue, Jul 8, 2008 at 3:30 PM, Anne Archibald
[EMAIL PROTECTED] wrote:
In particular, the returned type is always string of length four,
which is very peculiar - why four? I realize that variable-length
strings are a problem (object arrays, I guess?), as is returning
arrays of varying dtypes
Hi all,
I wanted to point out a couple of things about the new test framework
that you should keep in mind if you're writing tests:
- Don't use NumpyTestCase any more, just use TestCase (which is
available if you do from numpy.testing import *). Using NumpyTestCase
now causes a deprecation
On Wed, Jul 9, 2008 at 9:26 AM, Anne Archibald
[EMAIL PROTECTED] wrote:
- Test functions and methods will only be picked up based on name if
they begin with test; check_* will no longer be seen as a test
function.
Is it possible to induce nose to pick these up and, if not actually
run them,
On Wed, Jul 9, 2008 at 3:26 PM, Robert Kern [EMAIL PROTECTED] wrote:
I don't think it's worth automating on every run. People can see for
themselves if they have any such check_methods() and make the
conversion once:
Does this fall into the how in the world should I have known to do
that
There's a _get_truendim method on matrix that isn't referenced
anywhere in NumPy, SciPy, or matplotlib. Should this get deprecated
or removed in 1.2?
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
On Wed, Jul 9, 2008 at 4:23 PM, Robert Kern [EMAIL PROTECTED] wrote:
On Wed, Jul 9, 2008 at 15:16, Alan McIntyre [EMAIL PROTECTED] wrote:
There's a _get_truendim method on matrix that isn't referenced
anywhere in NumPy, SciPy, or matplotlib. Should this get deprecated
or removed in 1.2?
We
I'd like to make the following change to the chararray constructor.
This is motivated by some of chararray's methods constructing new
chararrays with NumPy integer arguments to itemsize, and it just
seemed easier to fix this in the constructor.
Index: numpy/numpy/core/defchararray.py
On Thu, Jul 10, 2008 at 10:06 AM, Christopher Hanley [EMAIL PROTECTED] wrote:
From the svn log it looks like the tests are intended to fail? However
I would prefer tests that are designed only to fail when problems
occur. Otherwise we end up with problems with our automatic build and
test
On Thu, Jul 10, 2008 at 8:14 PM, Robert Kern [EMAIL PROTECTED] wrote:
For things that you don't expect to be platform specific, there is no
need. For things that you do expect to be platform specific on
platforms that you cannot access, please ask for volunteers. Make an
SVN branch if the
Does anybody know whether there's any reason to keep the following
functions? They don't appear to be used anywhere.
linalg/linalg.py:95 _castCopyAndTranspose
lib/function_base.py:659 _asarray1d
___
Numpy-discussion mailing list
On Mon, Jul 14, 2008 at 1:31 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Any idea what this is:
*** DocTestRunner.merge: '__main__' in both testers; summing outcomes.
Hmm..that's coming from nose. I'll see what it's about tomorrow.
___
On Mon, Jul 14, 2008 at 7:58 PM, Fernando Perez [EMAIL PROTECTED] wrote:
It's actually coming from doctest. Hardcode
import doctest
doctest.master = None
in the code that runs the tests. This resets a module-global that's
the cause of that message.
Thanks, Fernando, I added that and it
On Mon, Jul 14, 2008 at 8:21 PM, Pierre GM [EMAIL PROTECTED] wrote:
I did as much as I could to ensure compatibility with Python 2.3, but I can't
test it myself (can't install Python 2.3 on my machine). It'd be great if
somebody could check it works with that version, otherwise I'm all go (the
On Wed, Jul 16, 2008 at 10:00 PM, Robert Kern [EMAIL PROTECTED] wrote:
Is there a way to do it programatically without requiring numpy to be
installed with setuptools?
There is; you have to pass a list of plugin instances to the
constructor of TestProgram--all plugins that you might want to
On Wed, Jul 16, 2008 at 11:32 PM, Robert Kern [EMAIL PROTECTED] wrote:
Since we're discussing this sort of thing, there's something I've been
meaning to ask anyway: do we really need to allow end users to pass in
arbitrary extra arguments to nose (via the extra_argv in test())?
This seems to
Which versions of Python are to be officially supported by NumPy 1.2?
I've been working against 2.5 and testing against 2.4 occasionally,
but 2.3 still has some issues I need to address (or at least that was
the case the last time I checked).
___
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] grin
This seems odd to me:
A=np.array([['%.3f','%d'],['%s','%r']]).view(np.chararray)
A % np.array([[1,2],[3,4]])
Traceback (most recent call last):
File stdin, line 1, in module
File /opt/local/lib/python2.5/site-packages/numpy/core/defchararray.py,
line 126, in __mod__
newarr[:] = res
On Fri, Jul 18, 2008 at 8:32 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
That looks like a bug to me. I would have expected at least one of
the following to work:
A % [[1, 2], [3, 4]]
A % 1
A % (1, 2, 3, 4)
and none of them do.
I wouldn't expect the last one to work, since the
1 - 100 of 122 matches
Mail list logo
