On Mon, Dec 20, 2010 at 1:42 PM, John Salvatier
jsalv...@u.washington.eduwrote:
A while ago, I asked a whether it was possible to multi-iterate over
several ndarrays but exclude a certain axis(
http://www.mail-archive.com/numpy-discussion@scipy.org/msg29204.html),
sort of a combination of
That's a good suggestion - added. Unfortunately, it looks like the github
rst converter doesn't make a table of contents with working links.
Cheers,
Mark
On Tue, Dec 21, 2010 at 6:00 PM, John Salvatier
jsalv...@u.washington.eduwrote:
I applaud you on your vision. I only have one small
On Tue, Dec 21, 2010 at 6:06 PM, David da...@silveregg.co.jp wrote:
snip
This looks pretty cool. I hope to be able to take a look at it during
the christmas holidays.
Thanks!
I cannot comment in details yet, but it seems to address several issues
I encountered myself while implementing
On Wed, Dec 22, 2010 at 12:21 AM, Francesc Alted fal...@pytables.orgwrote:
snip
Wow, really nice work! It would be great if that could make into NumPy
:-) Regarding your comment on numexpr being faster, I'm not sure (your
new_iterator branch does not work for me; it gives me an error like:
On Tue, Dec 21, 2010 at 10:05 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
snip
Wow, that's a really nice design and write up. Small typo:
/* Only allow exactly equivalent types */
NPY_NO_CASTING=0,
/* Allow casts between equivalent types of different byte
On Wed, Dec 22, 2010 at 12:54 AM, Francesc Alted fal...@pytables.orgwrote:
A Wednesday 22 December 2010 09:48:03 Mark Wiebe escrigué:
On Wed, Dec 22, 2010 at 12:21 AM, Francesc Alted
fal...@pytables.orgwrote:
snip
new_iterator branch does not work for me; it gives me an error
like
On Wed, Dec 22, 2010 at 12:44 AM, John Salvatier
jsalv...@u.washington.eduwrote:
This now makes sense to me, and I think it should work :D. This is all very
cool. This is going to do big things for cython and numpy.
Some hopefully constructive criticism:
When first reading through the API
On Wed, Dec 22, 2010 at 9:07 AM, Francesc Alted fal...@pytables.org wrote:
A Wednesday 22 December 2010 17:25:13 Mark Wiebe escrigué:
Can you print out your np.__version__, and try running the tests? If
newiter didn't build for some reason, its tests should be throwing a
bunch
On Wed, Dec 22, 2010 at 10:41 AM, Francesc Alted fal...@pytables.orgwrote:
NumPy version 2.0.0.dev-147f817
There's your problem, it looks like the PYTHONPATH isn't seeing your new
build for some reason. That build is off of this commit in the NumPy master
branch:
On Wed, Dec 22, 2010 at 11:16 AM, Francesc Alted fal...@pytables.orgwrote:
A Wednesday 22 December 2010 19:52:45 Mark Wiebe escrigué:
On Wed, Dec 22, 2010 at 10:41 AM, Francesc Alted
fal...@pytables.orgwrote:
NumPy version 2.0.0.dev-147f817
There's your problem, it looks like
On Wed, Dec 22, 2010 at 12:05 PM, Francesc Alted fal...@pytables.orgwrote:
snip
Ah, things go well now:
timeit 3*a+b-(a/c)
10 loops, best of 3: 67.7 ms per loop
timeit luf(lambda a,b,c:3*a+b-(a/c), a, b, c)
10 loops, best of 3: 27.8 ms per loop
timeit ne.evaluate(3*a+b-(a/c))
10
On Wed, Dec 22, 2010 at 12:42 PM, Mark Wiebe mwwi...@gmail.com wrote:
snip
I think numexpr could get a nice boost from using the new iterator
internally though
There's actually a trivial way to do this with very minimal changes to
numexpr - the 'itview' mechanism. Create the new iterator
On Sat, Jan 1, 2011 at 11:23 AM, John Salvatier
jsalv...@u.washington.eduwrote:
This thread is a bit old, but since it's not possible to use the C-API is
possible to accomplish this same thing with the Python API?
I've committed Python exposure for nested iteration to the new_iterator
branch.
and
numexpr's multithreading together will require some small additions to the
iterator.
Cheers,
Mark
On Tue, Jan 4, 2011 at 12:04 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sat, Jan 1, 2011 at 11:23 AM, John Salvatier
jsalv...@u.washington.edu wrote:
This thread is a bit old, but since it's
Oh, and I'm not sure about Cython, since I've never looked into its details.
I imagine Cython will want to short circuit some of the Python exposure
code, since accessing the iterator values creates new array objects.
-Mark
On Tue, Jan 4, 2011 at 12:59 PM, Mark Wiebe mwwi...@gmail.com wrote
On Tue, Jan 4, 2011 at 4:34 AM, David Cournapeau courn...@gmail.com wrote:
Ok, I took some time to look into it, but I am far from understanding
everything yet. I will need more time.
Yeah, it ended up being pretty large. I think the UFunc code will shrink
substantially when it uses this
On Wed, Jan 5, 2011 at 4:26 AM, Francesc Alted fal...@pytables.org wrote:
Sorry for the naive question, but I use the numpy.fromiter() iterator
quite a few in my projects. and I'm curious on whether this new
iterator would allow numpy.fromiter() to go faster (I mean, in Python
space). Any
As a benchmark of C-based iterator usage and to make it work properly in a
multi-threaded context, I've updated numexpr to use the new iterator. In
addition to some performance improvements, this also made it easy to add
optional out= and order= parameters to the evaluate function. The numexpr
or are
there other changes?
On Sun, Jan 9, 2011 at 2:45 PM, Mark Wiebe mwwi...@gmail.com wrote:
As a benchmark of C-based iterator usage and to make it work properly in a
multi-threaded context, I've updated numexpr to use the new iterator. In
addition to some performance improvements, this also made
On Mon, Jan 10, 2011 at 2:05 AM, Francesc Alted fal...@pytables.org wrote:
snip
Your patch looks mostly fine to my eyes; good job! Unfortunately, I've
been unable to compile your new_iterator branch of NumPy:
numpy/core/src/multiarray/multiarraymodule.c:45:33: fatal error:
On Mon, Jan 10, 2011 at 9:47 AM, Francesc Alted fal...@pytables.org wrote:
snip
so, the new code is just 5% slower. I suppose that removing the
NPY_ITER_ALIGNED flag would give us a bit more performance, but that's
great as it is now. How did you do that? Your new_iter branch in NumPy
I'm a bit curious why the jump from 1 to 2 threads is scaling so poorly.
Your timings have improvement factors of 1.85, 1.68, 1.64, and 1.79. Since
the computation is trivial data parallelism, and I believe it's still pretty
far off the memory bandwidth limit, I would expect a speedup of 1.95 or
On Mon, Jan 10, 2011 at 11:35 AM, Mark Wiebe mwwi...@gmail.com wrote:
I'm a bit curious why the jump from 1 to 2 threads is scaling so poorly.
Your timings have improvement factors of 1.85, 1.68, 1.64, and 1.79. Since
the computation is trivial data parallelism, and I believe it's still
On Wed, Jan 26, 2011 at 2:23 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Wed, Jan 26, 2011 at 12:28 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Jan 25, 2011 at 5:18 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Jan 25, 2011 at 1:13 PM, Travis Oliphant oliph
I wrote a new function, einsum, which implements Einstein summation
notation, and I'd like comments/thoughts from people who might be interested
in this kind of thing.
In testing it, it is also faster than many of NumPy's built-in functions,
except for dot and inner. At the bottom of this email
On Wed, Jan 26, 2011 at 1:36 PM, Joshua Holbrook josh.holbr...@gmail.comwrote:
On Wed, Jan 26, 2011 at 11:27 AM, Mark Wiebe mwwi...@gmail.com wrote:
I wrote a new function, einsum, which implements Einstein summation
notation, and I'd like comments/thoughts from people who might
On Wed, Jan 26, 2011 at 2:01 PM, Joshua Holbrook josh.holbr...@gmail.comwrote:
snip
How closely coupled is this new code with numpy's internals? That is,
could you factor it out into its own package? If so, then people could
have immediate use out of it without having to integrate it into
On Wed, Jan 26, 2011 at 3:05 PM, Joshua Holbrook josh.holbr...@gmail.comwrote:
It think his real question is whether einsum() and the iterator stuff
can live in a separate module that *uses* a released version of numpy
rather than a development branch.
--
Robert Kern
Indeed, I
On Wed, Jan 26, 2011 at 3:18 PM, Hanno Klemm kl...@phys.ethz.ch wrote:
Mark,
interesting idea. Given the fact that in 2-d euclidean metric, the
Einstein summation conventions are only a way to write out
conventional matrix multiplications, do you consider at some point to
include a
On Wed, Jan 26, 2011 at 6:41 PM, Jonathan Rocher jroc...@enthought.comwrote:
Nice function, and wonderful that it speeds some tasks up.
some feedback: the following notation is a little counter intuitive to me:
np.einsum('i...-', a)
array([50, 55, 60, 65, 70])
np.sum(a,
On Wed, Jan 26, 2011 at 5:23 PM, josef.p...@gmail.com wrote:
snip
So, if I read the examples correctly we finally get dot along an axis
np.einsum('ijk,ji-', a, b)
np.einsum('ijk,jik-k', a, b)
or something like this.
the notation might require getting used to but it doesn't look worse
On Wed, Jan 26, 2011 at 8:29 PM, Joshua Holbrook josh.holbr...@gmail.comwrote:
The only disadvantage I see, is that choosing the axes to operate on
in a program or function requires string manipulation.
One possibility would be for the Python exposure to accept lists or
tuples
of
On Thu, Jan 27, 2011 at 7:09 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
snip
The PIL test can still be fixed before the final 0.9.0 release, it looks
like we will need another RC anyway. Does anyone have time for this in the
next few days?
I've attached a patch which fixes it for
On Fri, Jan 28, 2011 at 1:18 PM, Travis Oliphant oliph...@enthought.comwrote:
Just to start the conversation, and to find out who is interested, I would
like to informally propose generator arrays for NumPy 2.0. This concept
has as one use-case, the deferred arrays that Mark Wiebe has
,
Mark
On Fri, Jan 28, 2011 at 7:19 AM, Bruce Southey bsout...@gmail.com wrote:
On 01/27/2011 10:58 PM, David Cournapeau wrote:
On Fri, Jan 28, 2011 at 12:46 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Hi All,
Mark Wiebe has proposed making the master branch backward compatible
On Fri, Jan 28, 2011 at 4:14 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
snip
Go ahead and merge it in and we'll see how it goes.
I did the merge, and tried to trigger the buildbot, but it looks like a
github svn issue has reared its head:
On Tue, Feb 1, 2011 at 3:58 PM, Pauli Virtanen p...@iki.fi wrote:
Hi,
The master branch did not build today on Python 3. Please make sure that
your code works correctly also on Python 3, before pushing it.
Sorry about that, I had hoped to be able to use the build-bot to
test/diagnose the
On Tue, Feb 1, 2011 at 9:49 PM, David da...@silveregg.co.jp wrote:
snip
In the meantime, I put the relevant header in numpy/core/src/private, to
make the dependency clearer.
Following that argument, there are other unwanted dependencies between
multiarray and ufunc, causing circular
On Tue, Feb 1, 2011 at 10:09 PM, David da...@silveregg.co.jp wrote:
On 02/02/2011 02:57 PM, Mark Wiebe wrote:
On Tue, Feb 1, 2011 at 9:49 PM, David da...@silveregg.co.jp
mailto:da...@silveregg.co.jp wrote:
snip
In the meantime, I put the relevant header in
numpy
Moving this to a new thread.
On Thu, Feb 3, 2011 at 10:50 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Thu, Feb 3, 2011 at 11:07 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Feb 1, 2011 at 10:09 PM, David da...@silveregg.co.jp wrote:
On 02/02/2011 02:57 PM, Mark Wiebe wrote
On Tue, Feb 8, 2011 at 10:49 AM, Pauli Virtanen p...@iki.fi wrote:
Tue, 08 Feb 2011 11:35:12 -0700, Charles R Harris wrote:
Permission to close ticket for Mark Wiebe
I don't know who handles these permissions, I didn't see a way to do it
myself.
Granted. (You'd need a shell account
On Thu, Feb 10, 2011 at 10:31 AM, Pauli Virtanen p...@iki.fi wrote:
Thu, 10 Feb 2011 12:16:12 -0600, Robert Kern wrote:
[clip]
One thing that might be worthwhile is to make
implementations of sum() and cumsum() that avoid the ufunc machinery and
do their iterations more quickly, at least
On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
snip
I've had a look at the bug tracker, here's a list of tickets for 1.6:
#1748 (blocker: regression for astype('str'))
#1619 (issue with dtypes, with patch)
#1749 (distutils, py 3.2)
#1601 (distutils,
On Fri, Mar 4, 2011 at 8:37 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote:
On Fri, Mar 4, 2011 at 5:00 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 3/3/2011 10:54 PM, Ralf Gommers wrote:
Before the first beta can be released I think #1748 should be fixed.
Before the first RC the
bad commit
commit d90f19abf18d59be959e04d73b3dbd7ae04b1e89
Author: Mark Wiebe mwwi...@gmail.com
Date: Mon Jan 17 18:26:12 2011 -0800
ENH: core: Change PyArray_MoveInto to use the new iterator as well
:04 04 a23fbcff385fca9704a5313e81217a6d80e3512c
On Sat, Mar 5, 2011 at 8:13 PM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Sat, Mar 5, 2011 at 9:00 PM, Travis Oliphant oliph...@enthought.comwrote:
My point is also that we need to make sure the broadcasting rules are
consistent for both addition and array copy.
Addition would
On Sat, Mar 5, 2011 at 8:13 PM, Travis Oliphant oliph...@enthought.comwrote:
On Mar 5, 2011, at 5:10 PM, Mark Wiebe wrote:
On Thu, Mar 3, 2011 at 10:54 PM, Ralf Gommers ralf.gomm...@googlemail.com
wrote:
snip
I've had a look at the bug tracker, here's a list of tickets for 1.6
On Mon, Mar 7, 2011 at 9:23 AM, Robert Kern robert.k...@gmail.com wrote:
On Mon, Mar 7, 2011 at 11:08, Christopher Barker chris.bar...@noaa.gov
wrote:
On 3/6/11 5:54 AM, Charles R Harris wrote:
I suppose this might cause a problem with lazy/quick c extensions that
expected elements in a
.
On Mon, Mar 7, 2011 at 8:30 PM, Francesc Alted fal...@pytables.org
fal...@pytables.org
wrote:
A Sunday 06 March 2011 06:47:34 Mark Wiebe escrigué:
I think it's ok to revert this behavior for backwards
compatibility,
but believe it's an inconsistent and unintuitive choice
On Fri, Mar 11, 2011 at 1:07 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Tue, Mar 8, 2011 at 1:35 AM, Pauli Virtanen p...@iki.fi wrote:
Structured array copying copies by field name.
Commit 22d96096bf7d5fb199ca80f2fcd04e8d27815476
Before:
x = np.array([(0, 1)],
On Fri, Mar 11, 2011 at 1:13 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Tue, Mar 8, 2011 at 1:35 AM, Pauli Virtanen p...@iki.fi wrote:
Ufuncs don't necessarily return arrays in C-order, but instead
try to keep the memory layout of the original if it seems
advantageous vs.
On Sun, Mar 13, 2011 at 1:22 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
Hi all,
On Tuesday (~2am GMT) I plan to create the 1.6.x branch and tag the
first beta. So please get your last commits for 1.6 in by Monday
evening.
Also, please review and add to the 1.6.0 release notes. I
On Sun, Mar 13, 2011 at 7:47 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Sun, Mar 13, 2011 at 8:23 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 13, 2011 at 1:22 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
Hi all,
On Tuesday (~2am GMT) I plan to create the 1.6
On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Mon, Mar 14, 2011 at 2:22 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 13, 2011 at 7:47 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sun, Mar 13, 2011 at 8:23 PM, Mark Wiebe mwwi
://en.wikipedia.org/wiki/Multi-index_notation).
On Mon, Mar 14, 2011 at 1:14 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Mon, Mar 14, 2011 at 2:22 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 13, 2011 at 7
On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Mon, Mar 14, 2011 at 2:22 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 13, 2011 at 7:47 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sun, Mar 13, 2011 at 8:23 PM, Mark Wiebe mwwi
On Tue, Mar 15, 2011 at 12:25 PM, Sebastian Haase seb.ha...@gmail.comwrote:
snip
Log Message:
---
ENH: Add 'subok' parameter to PyArray_NewLikeArray, np.empty_like,
np.zeros_like, and np.ones_like
This way, the sub-type can be avoided if necessary. This helps mitigate,
but
On Tue, Mar 15, 2011 at 8:29 PM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Wed, Mar 16, 2011 at 2:31 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Mar 15, 2011 at 12:26 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 13, 2011 at 11:59 PM, Ralf Gommers
, Mark Wiebe mwwi...@gmail.com wrote:
I pushed one more small API change to PyArray_NewLikeArray, adding a
'subok' parameter which lets you disable sub-types. The things missing
still
are documentation (maybe others can help?). The Python nditer exposure is
undocumented, as well as the new
become
clear in the meantime.
I'm almost done bisecting.
6c6dc487ca15818d1f4cc764debb15d73a61c03b is the first bad commit
commit 6c6dc487ca15818d1f4cc764debb15d73a61c03b
Author: Mark Wiebe mwwi...@gmail.com
Date: Thu Jan 20 20:41:03 2011 -0800
ENH: ufunc: Made the iterator ufunc default
On Wed, Mar 16, 2011 at 10:53 AM, Robert Kern robert.k...@gmail.com wrote:
On Wed, Mar 16, 2011 at 12:15, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Mar 16, 2011 at 10:00 AM, Robert Kern robert.k...@gmail.com
wrote:
On Wed, Mar 16, 2011 at 11:55, Robert Kern robert.k...@gmail.com
wrote
On Thu, Mar 17, 2011 at 2:35 PM, Robert Kern robert.k...@gmail.com wrote:
On Wed, Mar 16, 2011 at 15:21, Mark Wiebe mwwi...@gmail.com wrote:
That sounds like a good fix to me. Whenever objects compare equal, they
should hash to the same value.
There is a limit to how far we can actually
On Thu, Mar 17, 2011 at 3:30 PM, Pauli Virtanen p...@iki.fi wrote:
Thu, 17 Mar 2011 15:23:19 -0700, Christopher Barker wrote:
On 3/17/11 2:57 PM, Mark Wiebe wrote:
Dtypes being mutable looks like a serious bug to me, it's violating the
definition of 'hashable' given here:
I can imagine
I noticed that the nditer documentation didn't get linked properly, this
fixes it. You might want to cherry-pick the patch I committed to master so
it shows up.
-Mark
On Tue, Mar 22, 2011 at 10:29 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
Hi,
After tagging 1.6.0b1 and pushing it I
On Thu, Mar 24, 2011 at 8:22 PM, David da...@silveregg.co.jp wrote:
Hi Mark, hi all,
I noticed you did a lot of cleaning in the bug trackers, thank you for
helping there, this is sorely needed.
However, I noticed quite a few tickets were closed as wontfix even
though they are valid. I
On Fri, Mar 25, 2011 at 10:21 AM, Pauli Virtanen p...@iki.fi wrote:
Fri, 25 Mar 2011 10:00:24 -0700, Eli Stevens (Gmail) wrote:
I'm working on getting support for 16-bit floats into cython and have
run into what seems like a numpy bug (I'm a new contributor to both
projects, so bear with
On Fri, Mar 25, 2011 at 11:14 AM, Eli Stevens (Gmail)
wickedg...@gmail.comwrote:
On Fri, Mar 25, 2011 at 10:35 AM, Mark Wiebe mwwi...@gmail.com wrote:
That said, I think starting a discussion with the Python core developers
about the float16 type is worthwhile. There might be interest
On Fri, Mar 25, 2011 at 11:28 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Fri, Mar 25, 2011 at 11:14 AM, Eli Stevens (Gmail)
wickedg...@gmail.com wrote:
On Fri, Mar 25, 2011 at 10:35 AM, Mark Wiebe mwwi...@gmail.com wrote:
That said, I think starting a discussion with the Python core
It turns out that Python 2.6 complex doesn't implement __format__, and that
results in the problem.
http://web.archiveorange.com/archive/v/jA6s92Ni29ENZpi4rpz5
I've disabled the complex formatting tests for 2.6 in
commit 7d436cc8994f9efbc512.
On Mon, Mar 28, 2011 at 10:45 AM, Eli Stevens (Gmail)
wickedg...@gmail.comwrote:
On Fri, Mar 25, 2011 at 11:14 AM, Eli Stevens (Gmail)
wickedg...@gmail.com wrote:
On Fri, Mar 25, 2011 at 10:35 AM, Mark Wiebe mwwi...@gmail.com wrote:
That said, I think starting a discussion with the Python
On Wed, Mar 30, 2011 at 4:42 PM, Eli Stevens (Gmail)
wickedg...@gmail.comwrote:
On Fri, Mar 25, 2011 at 10:00 AM, Eli Stevens (Gmail)
wickedg...@gmail.com wrote:
Can anyone please give me some suggestions on how to go about writing
a unit test for this? Or should I just submit a pull
On Thu, Mar 31, 2011 at 10:40 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Thu, Mar 31, 2011 at 7:06 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Mar 30, 2011 at 4:42 PM, Eli Stevens (Gmail)
wickedg...@gmail.com
wrote:
On Fri, Mar 25, 2011 at 10:00 AM, Eli Stevens (Gmail
On Thu, Mar 31, 2011 at 11:45 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Thu, Mar 31, 2011 at 8:37 PM, Eli Stevens (Gmail)
wickedg...@gmail.com wrote:
On Thu, Mar 31, 2011 at 10:40 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
It would definitely need to get into beta 2,
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu wrote:
snip
A few numpy tests fail on win-amd64:
snip
==
FAIL: test_iterator.test_iter_broadcasting_errors
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
snip
A few numpy tests fail on win-amd64:
snip
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at 9:10 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
snip
A few numpy tests fail on win-amd64:
snip
On Tue, Apr 5, 2011 at 7:21 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/5/2011 6:46 PM, Mark Wiebe wrote:
On Tue, Apr 5, 2011 at 5:07 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
On 4/5/2011 4:05 PM, Mark Wiebe wrote:
On Mon, Apr 4, 2011 at 9
On Mon, Apr 11, 2011 at 12:37 PM, Robert Kern robert.k...@gmail.com wrote:
On Mon, Apr 11, 2011 at 13:54, Skipper Seabold jsseab...@gmail.com
wrote:
All,
We noticed some failing tests for statsmodels between numpy 1.5.1 and
numpy = 1.6.0. These are the versions where I noticed the
On Mon, Apr 11, 2011 at 8:48 PM, Travis Oliphant oliph...@enthought.comwrote:
On Apr 11, 2011, at 3:55 PM, Charles R Harris wrote:
snip
I agree with Charles. Let's take the needed time and work this through.
This is the sort of thing I was a bit nervous about with the changes made to
the
On Tue, Apr 12, 2011 at 9:30 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Apr 12, 2011 at 11:20, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Apr 12, 2011 at 8:24 AM, Robert Kern robert.k...@gmail.com
wrote:
On Mon, Apr 11, 2011 at 23:43, Mark Wiebe mwwi...@gmail.com wrote
On Tue, Apr 12, 2011 at 11:17 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Tue, Apr 12, 2011 at 11:56 AM, Robert Kern robert.k...@gmail.comwrote:
On Tue, Apr 12, 2011 at 12:27, Charles R Harris
charlesr.har...@gmail.com wrote:
IIRC, the behavior with respect to scalars sort
On Tue, Apr 12, 2011 at 11:51 AM, Mark Wiebe mwwi...@gmail.com wrote:
snip
here's the rule for a set of arbitrary arrays (not necessarily just 2):
- if all the arrays are scalars, do type promotion on the types as is
- otherwise, do type promotion on min_scalar_type(a) of each array
On Wed, Apr 13, 2011 at 3:34 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Apr 12, 2011 at 11:51 AM, Mark Wiebe mwwi...@gmail.com wrote:
snip
here's the rule for a set of arbitrary arrays (not necessarily just 2):
- if all the arrays are scalars, do type promotion on the types
On Sun, Apr 17, 2011 at 8:55 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
Hi,
The list of open issues for 1.6.0 is down to a handful:
- f2py segfault on Ubuntu reported by David (David, did you get any
further with this?)
- #1801: test_noncentral_f failure on win64
- #1798: type
On Fri, Apr 22, 2011 at 5:08 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/22/2011 2:52 PM, Gökhan Sever wrote:
On Fri, Apr 22, 2011 at 12:37 PM, Ralf Gommers
ralf.gomm...@googlemail.com mailto:ralf.gomm...@googlemail.com
wrote:
On Thu, Apr 21, 2011 at 10:06 PM, Gökhan
On Sat, Apr 30, 2011 at 9:11 PM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/30/2011 6:37 PM, Charles R Harris wrote:
On Sat, Apr 30, 2011 at 6:50 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
On 4/30/2011 4:58 PM, Charles R Harris wrote:
On Sun, May 1, 2011 at 12:19 AM, Christoph Gohlke cgoh...@uci.edu wrote:
On 4/30/2011 9:27 PM, Mark Wiebe wrote:
On Sat, Apr 30, 2011 at 9:11 PM, Christoph Gohlke cgoh...@uci.edu
mailto:cgoh...@uci.edu wrote:
On 4/30/2011 6:37 PM, Charles R Harris wrote:
On Sat, Apr
I applied everything, since they're all obviously bugs and the fixes look
straightforward.
-Mark
On Mon, May 2, 2011 at 8:18 AM, Michael Droettboom md...@stsci.edu wrote:
I've found a few reference counting bugs running the regression tests
under Valgrind. Pull request here:
On Wed, May 4, 2011 at 6:19 AM, Christoph Groth c...@falma.de wrote:
Dear numpy experts,
I have noticed that with Numpy 1.5.1 the operation
m[::2] += 1.0
takes twice as long as
t = m[::2]
t += 1.0
where m is some large matrix. This is of course because the first
snippet is
On Tue, May 17, 2011 at 8:53 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Tue, May 17, 2011 at 7:46 PM, Wieland Brendel
wielandbren...@gmx.netwrote:
The equality being that the expression should be ~0?
Exactly.
I see the problem when the last index is in the range 235 -
On Thu, May 19, 2011 at 6:59 AM, Pauli Virtanen p...@iki.fi wrote:
Thu, 19 May 2011 12:36:22 +0100, Mark Dickinson wrote:
[clip]
from numpy import array
x = array((1.2, 2.3), dtype=[('field1', float), ('field2', float)])
x.astype(object)
array(1.2, dtype=object)
Was this change
It's so we can see what bugs are actually fixed for 2.0 (as opposed to a
prior release), and a bug that's marked 'closed' but Unscheduled simply
doesn't make sense to me.
-Mark
On Tue, May 31, 2011 at 9:20 AM, Pierre GM pgmdevl...@gmail.com wrote:
All,
Could somebody tell me the advantage of
On Tue, May 31, 2011 at 10:09 AM, Pierre GM pgmdevl...@gmail.com wrote:
On May 31, 2011, at 4:25 PM, Mark Wiebe wrote:
It's so we can see what bugs are actually fixed for 2.0 (as opposed to a
prior release), and a bug that's marked 'closed' but Unscheduled simply
doesn't make sense to me
On Tue, May 31, 2011 at 11:14 AM, Pierre GM pgmdevl...@gmail.com wrote:
On May 31, 2011, at 6:06 PM, Bruce Southey wrote:
On 05/31/2011 10:33 AM, Mark Wiebe wrote:
On Tue, May 31, 2011 at 10:09 AM, Pierre GM pgmdevl...@gmail.com
wrote:
On May 31, 2011, at 4:25 PM, Mark Wiebe wrote
Hey all,
So I'm doing a summer internship at Enthought, and the first thing they
asked me to look into is finishing the datetime type in numpy. It turns out
that the estimates of how complete the type was weren't accurate, and to
support what the NEP describes required generalizing the ufunc type
On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris
charlesr.har...@gmail.comwrote:
snip
Just a quick comment, as this really needs more thought, but time is a bag
of worms.
Certainly a bag of worms, I agree.
Trying to represent some standard -- say seconds at the solar system
barycenter
On Wed, Jun 1, 2011 at 4:01 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote:
On Wed, Jun 1, 2011 at 10:05 PM, Mark Wiebe mwwi...@gmail.com wrote:
Hey all,
So I'm doing a summer internship at Enthought, and the first thing they
asked me to look into is finishing the datetime type
, Jun 1, 2011 at 10:29 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Jun 1, 2011 at 3:16 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
snip
Just a quick comment, as this really needs more
On Thu, Jun 2, 2011 at 11:22 AM, Christopher Barker
chris.bar...@noaa.govwrote:
Charles R Harris wrote:
Good support for units and delta times is very useful, but
parsing dates and times and handling timezones, daylight savings, leap
seconds, business days, etc., is probably best served
On Thu, Jun 2, 2011 at 11:57 AM, Christopher Barker
chris.bar...@noaa.govwrote:
Mark Wiebe wrote:
I'm following what I understand the NEP to mean for combining dates and
deltas of different units. This means for timedeltas, the metadata
becomes more precise, in particular it becomes
101 - 200 of 444 matches
Mail list logo
