, but my understanding
is that numpy.linalg.inv actually solves Ax = I instead of literally
calculating the inverse of A. It would be great if I can get some
intuition about this.
That's the same thing as computing the inverse matrix.
--
Pauli Virtanen
in lapack_lite.
numpy.linalg.pinv OTOH does use SVD, but that's probably more costly.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
/doc/numpy/dev/gitwash/patching.html
(iii) File a bug ticket.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 04 Nov 2010 13:33:48 +0100, Francesc Alted wrote:
[clip]
To solve this, just apply byteswap once more:
a = np.int32(300)
a.byteswap().byteswap()
300
and you are done.
Or directly specify big-endian byte order when reading
fromfile(fp, 'i4', 3)
to github?
That would require more work on the Trac-Git integration front:
http://github.com/pv/githubsimple-trac
It might be more cost-effective to just use links to the Github web
interface.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
Wed, 03 Nov 2010 12:39:08 +0100, Vincent Schut wrote:
[clip]
Btw, should I file a bug on this?
One can argue that mean() and sum() should use a numerically stabler
algorithm, so yes, a bug can be filed if there is not yet one already.
--
Pauli Virtanen
context.
Note also that at least Python's struct module (mis-?)uses __index__()
for casting inputs to integers.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
miss).
That's why I said that __getattr__ would perhaps work better.
So do you want me to try out an implementation and supply a patch? If
so, where should I send the patch?
See here:
http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
--
Pauli Virtanen
pe, 2010-10-29 kello 12:48 +0200, Francesc Alted kirjoitti:
A Friday 29 October 2010 12:18:20 Pauli Virtanen escrigué:
Fri, 29 Oct 2010 09:54:23 +0200, Francesc Alted wrote:
[clip]
My vote is +1 for deprecating ``array([scalar])`` as a scalar index
for NumPy 2.0.
I'd be -0
slots are consulted before falling back to tp_getattro. If tp_getattro is
consulted first, then implementing it will lead to a performance hit.
I'd probably be +0 on providing recarray-like functionality on ordinary
ndarrays, if it can be done without (significant) performance issues.
--
Pauli
want to chip in:
x = np.zeros((2, 3), dtype=[('a', 'f8', (4,))])
x.T['a'].shape
(4, 3, 2)
x.T.copy()['a'].shape
(3, 2, 4)
Fortran-order is special-cased. We might want to change this to work like
so:
x.T['a'].shape
(3, 2, 4)
which is more predictable.
--
Pauli Virtanen
])
PyArray_OrderConverter interprets `None` as A. However, this problem is
already there with `reshape`, so this patch looks good to me -- fixing
OrderConverter is a separate job.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
() does return when it sees the first True, but this is not full
short-circuiting.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
a report. Be sure to include simple test case (like the one you
attached).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, though.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
, but apparently not. So you're right
that the correct place to do the shape check is on the dtype level.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
(on subdtype): If a field whose dtype object has this attribute is
retrieved, then the extra dimensions implied by the shape are tacked on to
the end of the retrieved array.
IMO, it should be possible to change this with little prior notice.
A can of worms :)
--
Pauli Virtanen
Wed, 20 Oct 2010 19:21:15 +0200, Nils Wagner wrote:
test_duplicate_field_names_assign
(test_regression.TestRegression) ...
Works for me. This is exactly the crash that the test tests, so perhaps
you have an incomplete rebuild. I'd try rm -rf build and rebuild.
--
Pauli Virtanen
Tue, 19 Oct 2010 21:26:38 +1300, Alex Ter-Sarkissov wrote:
thanks, this didn't seem to work. I get a whole range of errors, most
importantly
SystemError: Cannot compiler 'Python.h'. Perhaps you need to install
python-dev|python-devel.
I think you should do sudo apt-get install python-dev
reduced to a single
boolean.
You can also initialize
dimensions = shape(self) + (-1,)
and let PyArray_Newshape do the size calculation for you.
I guess it's best to not initialize structures directly, if there is some
suspicion that obscure compilers don't like it.
--
Pauli Virtanen
Sat, 16 Oct 2010 23:23:46 -0600, Charles R Harris wrote:
[clip]
And I just managed the same result on a push to maintenance/1.5.x :-/
But I know how it happened, I cherry picked from master for a backport
before updating the 1.5.x branch from github. In Retrospect I probably
should have reset
Mon, 18 Oct 2010 09:07:42 -0400, Ian Goodfellow wrote:
To do a standard installation, run
sudo python setup.py install
from inside the numpy directory
Preferably,
sudo python setup.py install --prefix=/usr/local
and then you don't mess up your package manager.
Pauli
Mon, 18 Oct 2010 12:20:00 +0300, Pearu Peterson wrote:
[clip]
I see that there are long discussions in numpy ml about the git usage
and mis usage. I wonder whether this has converged to something that
could be used as reference for git beginners like me.
I think there's agreement on what we
the result of
a merge against the wrong parent (but of course there is no way to know
which is the right one).
The problems with the commit, as far as I see:
- adds unrelated Eclipse .project and .pydev* files
- introduces a merge commit for a small change
--
Pauli Virtanen
? Who would decide?
I think it is best to discuss this now, and make sure all core devs have
similar ideas on what is ideal.
One change at a time (i.e. give 'em the little finger approach).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Tue, 12 Oct 2010 13:55:27 -0600, Vincent Davis wrote:
It's meant for easy inclusion in other projects (if they agree with the
worfklow it presents), here it is for example rendered with the urls
pointing to ipython repos:
Hope something like this gets converted/done for Numpy.
Mon, 11 Oct 2010 23:30:31 +0200, Pierre GM wrote:
Would any of you mind giving me commit rights on github? My handle is
pierregm. Thanks a million in advance.
Granted.
Cheers,
Pauli
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
the
naming issue and open a ticket so we can start rationalizing this for
2.0? I'm thinking having pareto1 and lomax, or maybe pareto1 and
pareto2, and deprecating plain old pareto may be the way to go.
The documentation bit can be done, however, if there's a plan how to deal
with it.
--
Pauli
Fri, 08 Oct 2010 13:28:01 -0400, josef.pktd wrote:
[clip]
I think I clarified the doc string enough that user that read the
docstring don't get confused anymore.
http://docs.scipy.org/numpy/docs/numpy.random.mtrand.RandomState.pareto/
At least the first part is explicit about it, the notes
Thu, 07 Oct 2010 16:34:46 +0800, Ralf Gommers wrote:
[clip]
A 1.5.1 release soon would be good. All the issues above are already
committed, is there anything else that needs to go in? If not, I think
an RC by the end of next week (10/17) and release by the end of the
month should be possible.
Thu, 07 Oct 2010 07:09:37 -0600, Charles R Harris wrote:
[clip]
No, I just wanted to include the Laguerre and Hermite polynomials and
add a domain keyword to the linspace method of the polynomial template.
But I don't think these are pressing needs.
It's a minor release, so I think we need to
storage of re/im conflicts with its memory model. I
believe this will simply not be done, since there seems to be little
need for such a feature.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
Thu, 07 Oct 2010 18:02:43 -0400, Andrew P. Mullhaupt wrote:
On 10/7/2010 3:45 PM, josef.p...@gmail.com wrote:
what's your namespace?from scipy import log
log(int(-2))
(0.69314718055994529+3.1415926535897931j)
This should explain:
R = ones(2)
R[0] = R[0] * 1j
R
array([ 0., 1.])
Hi,
Should we set a date for a bugfix 1.5.1 release? There are some bugs that
would be nice to sort out in the 1.5.x series:
Any Python versions:
- #1605 (Cython vs. PEP-3118 issue: raising exceptions with active
cython buffers caused undefined behavior. Breaks Sage.)
- #1617 (Ensure
Thu, 30 Sep 2010 15:13:04 -0400, Michael Droettboom wrote:
Is the solution as simple as the attached diff? It works for me, but I
don't understand all the implications.
More or less so, applied.
Pauli
___
NumPy-Discussion mailing list
this trick.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
?
It probably shouldn't do *that* at the least.
http://projects.scipy.org/numpy/ticket/1618
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
the reason for
x.real is x
True
x.imag
array([0], dtype=object)
But it is a minor corner case, and there may be backward compatibility
issues in changing it.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
Mon, 20 Sep 2010 23:34:58 +0200, Hagen Fürstenau wrote:
I don't know if I'm overlooking something obvious, but is there a
compact way of computing the 3-array
X_{ijk} = \sum_{l} A_{il}*B_{jl}*C_{kl}
out of the 2-arrays A, B, and C?
Dear all,
Numpy SVN repository is now frozen, and does not accept new commits.
Future development should end up in the Git repository:
http://github.com/numpy/numpy
The next things on the TODO list:
- Update any links that point to http://svn.scipy.org/svn/numpy
or talk about SVN.
Thu, 16 Sep 2010 08:58:46 +, Pauli Virtanen wrote:
The next things on the TODO list:
- Update any links that point to http://svn.scipy.org/svn/numpy
or talk about SVN.
E.g. numpy.org needs updating.
- Put up documentation on how to contribute to Numpy via Git
Also look at CPython's objimpl.h, union _gc_head, you will see an
unprotected usage of 'long double', so it seems that CPython requires
that the C compiler to support 'long double'.
Long double is IIRC in C89, so compiler support is probably not a problem
nowadays.
--
Pauli Virtanen
. But let's do this directly in Git, so that I don't
have to bother regenerating the Numpy repo.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
).astype(i4).dtype
dtype('i4')
np.array(42, dtype=i4).astype('i4').dtype
dtype('int32')
Doesn't seem correct -- please file a bug ticket.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo
Mon, 13 Sep 2010 15:33:11 -0500, Travis Oliphant wrote:
Are we ready to do this yet?
I know there were some outstanding questions. Are there major concerns
remaining?
As far as the conversion is concerned, things should be OK.
The bugs in svn-all-fast-export have been fixed in the meantime,
Mon, 13 Sep 2010 21:41:18 +, Pauli Virtanen wrote:
[clip]
I can upload a final repository today/tomorrow. If it seems OK, we can
freeze SVN trunk a few days after that.
Or we can freeze the trunk sooner than that after the final repo is
up, and patch up things manually, if something
Mon, 13 Sep 2010 18:08:39 -0600, Charles R Harris wrote:
[clip]
What is the suggested work flow for the new repositories? Is the best
way to use a github fork and push and pull from that?
Yes, I'd personally work like that. Easier to keep private stuff separate.
Pauli
Mon, 13 Sep 2010 18:15:01 -0600, Charles R Harris wrote:
[clip]
I think we should freeze the svn repo as soon as possible. Pierre is
still making commits there and unless there is an easy way to update the
git repo from svn those sort of commits might be a small hassle.
It needs re-generation
product.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 10 Sep 2010 14:35:46 +0200, Radek Machulka wrote:
Thanks, but...
x = array([[0,0,0,0],[0,1,0,0],[0,0,1,1],[0,0,0,0]]) x
array([[0, 0, 0, 0],
[0, 1, 0, 0],
[0, 0, 1, 1],
[0, 0, 0, 0]])
i, j = x.any(0).nonzero()[0], x.any(1).nonzero()[0]
Should be
j, i =
not to include such a wrapper, so little
persuasion is needed. The only thing is that someone should spend some
time implementing this suggestion (and I probably won't -- I don't really
need that feature myself, and there are many other things that need to be
done).
--
Pauli Virtanen
/to/liblapack.so ...
may work. This'll probably even make it to the documentation one day...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Mon, 06 Sep 2010 10:41:38 +0200, Sebastian Haase wrote:
is there an URL of the weekly built CHM documentation file ?
It's the one linked from http://docs.scipy.org/doc/
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
be a problem. I'm not an
expert on this, however.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- if you need C-contiguity, you'll need to ensure it by using
`ascontiguousarray`.
Especially when we later on implement memory access pattern optimizations
for ufuncs, such assumptions will break down even more often.
--
Pauli Virtanen
___
NumPy
that call sscanf with the correct format string in the end.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 02 Sep 2010 08:27:18 -0600, Charles R Harris wrote:
[clip]
Hi Pauli, I gave it a quick spin and it looks good so far. The cloning
was really fast, I like that ;) Is there any way to test out commiting?
I didn't have permissions to push to the repository.
You should have push permissions
branches/fix_float_format in SVN that got later on merged to
trunk. Github seems to show these in different colors, but in reality
they are just a part of the master branch history.
So all in all, it looks correct to me.
--
Pauli Virtanen
___
NumPy
float96(0.0001), the result is not the float96 number
closest to 0.0001, but the 96-bit representation of the 64-bit number
closest to 0.0001. Indeed,
float96(0.0001), float96(1.0)/1000
(0.0001479, 0.0009996)
--
Pauli Virtanen
-- it's the same issue. It's also a minor issue, IMHO, as I doubt
many people construct array scalars from strings, and even less do it in
bases other than 10. The fix is to change array scalar __new__, but this
is not completely straightforward to do. Patches are welcome.
--
Pauli Virtanen
Mon, 23 Aug 2010 21:15:55 +, Pauli Virtanen wrote:
[clip]
in the history to have the wrong content -- so to be sure, we have to do
a brute-force comparison of the tree against SVN for each commit. The
particular bug here was fixed in the conversion tool, but better safe
than sorry.
Also
Mon, 23 Aug 2010 15:30:19 -0500, Travis Oliphant wrote:
I'm curious as to the status of the Github migration and if there is
anything I can do to help. I have a couple of weeks right now and I
would love to see us make the transition of both NumPy and SciPy to GIT.
I think the more or less
Mon, 23 Aug 2010 23:31:14 +0200, Stéfan van der Walt wrote:
[clip]
Erk. What's the quickest route to go: compare the actual patches, or
bring a tree up to date for each revision and compute some sort of
working-copy checksum?
Working-copy checksumming is probably the easiest and most robust
of Numpy. On Python versions = 2.6 Numpy arrays expose the buffer
interface, and array(), asarray() and other functions accept new-style buffers
as input.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
since 1.4.x are unrelated.
I think the support for platform-provided complex functions was enabled
in r7986.
To be sure, we'd need to see the build log.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
Wed, 04 Aug 2010 23:34:15 +0800, Ralf Gommers wrote:
[clip]
I haven't started using py3k yet so I'm still a bit fuzzy about bytes
vs string. But it's easy to try in the interpreter:
import re
RE_VERSION = re.compile('(\d+\.\d+(\.\d+)*)')
In the Python 3.1 version I have, this line reads
, category, stack_level);
(gdb)
That was probably fixed in r8394 in trunk.
But to be sure, can you supply the whole stack trace (type bt in the
gdb prompt).
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
Mon, 02 Aug 2010 23:48:52 +0800, Ralf Gommers wrote:
I'm trying to get building to work with Python 3.1 under Wine on OS X.
The first thing you run into is a python distutils problem, which is
fixed by replacing line 379 of cygwinccompiler.py with
result =
to be included in the source distribution --
tools/py3tool.py seems to be missing from the tarball.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
this part of the distutils code on Python 3, and indeed
it does not have any tests, so it's not a surprise that stuff like this
is left over :)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org
of inspect (and hacks like this) into an
internal utility module that is fast to import.
We actually have `numpy.compat._inspect` and
from numpy.compat import getargspec
that could be used here.
--
Pauli Virtanen
___
NumPy-Discussion mailing
Fri, 30 Jul 2010 19:52:37 +0900, David wrote:
[clip]
Indeed, it is not, and that's expected. There are various pitfalls using
floating point. Rational and explanations:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
In case of tl;dr, see also http://floating-point-gui.de/
--
Pauli
Fri, 30 Jul 2010 14:21:23 +0200, Guillaume Chérel wrote:
[clip]
As for the details about my problem, I'm trying to compute the total
surface of overlapping disks. I approximate the surface with a grid and
count how many points of the grid fall into at least one disk.
HTH,
import numpy as np
as: mask[i0:j0,i1:j1] |= (grid_x[i0:j0,i1:j1] ...
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 29 Jul 2010 02:40:00 +0200, Sturla Molden wrote:
Mon, 26 Jul 2010 23:58:11 +0800, Ralf Gommers wrote:
Is the current algorithm in the trunk the ziggurat one, or the previous
one? IIRC, the problem was that the ziggurat broke reproducibility of
random numbers with a given seed.
Ziggurat
Thu, 29 Jul 2010 23:39:19 +0800, Ralf Gommers wrote:
The execfile builtin has disappeared in python 3.x, so I'm trying to
find another solution for the use of it in setupegg.py. So far I've
tried
I'd do something like this in setup.py:
...
+ if os.environ.get('USE_SETUPTOOLS'):
+
The above indeed shows that you are probably using 1.4.1, but the scipy
you import was compiled against either the SVN version of Numpy or 1.4.0.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
Wed, 28 Jul 2010 12:17:27 +0900, David Cournapeau wrote:
[clip]
http://github.com/numpy/numpy_svn
I put a new repostory (same location)
Some more notes:
- 1.1.x branch is missing.
This is maybe because in SVN something ugly was done with this branch?
- Something is still funny with some
Wed, 28 Jul 2010 12:17:27 +0900, David Cournapeau wrote:
[clip]
http://github.com/numpy/numpy_svn
I put a new repostory (same location)
Compared this against git-svn produced repository. There are a number of
commits missing from the early history, apparently because numpy trunk
was moved
the size
of the array item.
(or are recarrays pointers-of-pointers as opposed
to contiguous memory?)
No.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
citizens in the Python world. This sits less well with
Numpy: (i) Numpy tries to sit close to the hardware, and (ii) strictly
speaking, arbitrary-size integers cannot be a Numpy scalar type since
they by definition are not fixed-size in memory.
--
Pauli Virtanen
? IIRC, the problem was that the ziggurat broke reproducibility of
random numbers with a given seed.
So, was the ziggurat algorithm pulled out, or is it still there?
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http
Thu, 29 Jul 2010 01:16:14 +0200, Sturla Molden wrote:
[clip]
Makes sense. But couldn't a ``dtype`` argument still be useful?
np.ceil(some_array).astype(int)
That's one temporary more. The dtype= argument for all ufuncs wouldn't
probably hurt too much.
--
Pauli Virtanen
2
Aug 29: release
Seems OK. I don't remember any big changes that would still be needed.
One low-hanging fruit to fix could be np.fromfile raising MemoryError
when it encounters EOF, and other bugs in that part of the code.
--
Pauli Virtanen
Tue, 27 Jul 2010 10:50:51 -0700, Christopher Barker wrote:
Pauli Virtanen wrote:
Tue, 27 Jul 2010 08:37:56 -0600, Jed Ludlow wrote:
On Tue, Jul 27, 2010 at 2:38 AM, Pauli Virtanen p...@iki.fi wrote:
One low-hanging fruit to fix could be np.fromfile raising MemoryError
when it encounters EOF
Mon, 26 Jul 2010 13:57:36 +0900, David Cournapeau wrote:
I have finally prepared and uploaded a test repository containing numpy
code:
http://github.com/numpy/numpy_svn
Some observations based on a quick look:
1)
$ git branch -r
origin/maintenance/1.1.x_5227
Tue, 27 Jul 2010 00:26:51 +0800, Ralf Gommers wrote:
[clip]
Also, Ralf has the Git ID in format rgommers...email..., but I
guess that's correct?
My checkout failed so can't check this, but that looks a little odd. My
.gitconfig is normal:
user]
name = rgommers
email =
(most recent call last):
File stdin, line 1, in module
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in
position 0: ordinal not in range(128)
You probably meant to use byte strings, though:
string = b.join(chr(i).encode('latin1') for i in range(256))
--
Pauli Virtanen
in their own projects
I'm not sure what's the best place to put these in.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
the different attributes
(or specifically, how to keep them together during a sort).
What're my options?
One option could be to use structured arrays to store the data, instead
of Python objects.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
that changing reduce behavior would require us to
special-case the above two operations.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
that is otherwise a *left*
fold is very odd, no matter how you slice it. That is what looks like
special casing...
I think I see your point now.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
, those can be emulated with strides:
http://mentat.za.net/numpy/scipy2009/stefanv_numpy_advanced.pdf
http://conference.scipy.org/scipy2010/slides/tutorials
/stefan_vd_walt_numpy_advanced.pdf
--
Pauli Virtanen
___
NumPy-Discussion
the C int type happens to be.
Maybe someone can correct me here, but AFAIK it goes like so.
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Thu, 22 Jul 2010 15:00:50 -0500, Johann Hibschman wrote:
[clip]
Now, I'm on an older version (1.3.0), which might be the problem, but
which is correct here, the code or the docs?
The documentation is incorrect.
--
Pauli Virtanen
___
NumPy
this. http://docs.scipy.org/doc/numpy/reference/routines.set.html
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
However, nans have been propagated by maximum and minimum since 1.4.0.
There was a question, discussed on the list, as to what 'nan' complex to
return in the propagation, but it was still a nan complex in your
definition of such objects. The final choice was driven by using the
first of the
np.array([0,0], dtype=np.complex256)
--
Pauli Virtanen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
401 - 500 of 995 matches
Mail list logo
