On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving irv...@naml.us wrote:
snip
Back to the bugs: here's a branch with all the changes I needed to get
rational arithmetic to work:
https://github.com/girving/numpy
I discovered two more after the last email. One is another simple 0
vs. 1
On Mon, Dec 5, 2011 at 8:58 AM, David Cournapeau courn...@gmail.com wrote:
On Sun, Dec 4, 2011 at 9:45 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
We'll see how much interest there is. If it becomes official you may get
more feedback on features. There are some advantages to
On Mon, Dec 5, 2011 at 9:37 AM, mark florisson markflorisso...@gmail.comwrote:
On 5 December 2011 17:25, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving irv...@naml.us wrote:
snip
Back to the bugs: here's a branch with all the changes I needed
On Sat, Dec 3, 2011 at 6:18 PM, Travis Oliphant teoliph...@gmail.comwrote:
Hi everyone,
There have been some wonderfully vigorous discussions over the past few
months that have made it clear that we need some clarity about how
decisions will be made in the NumPy community.
When we were a
On Tue, Dec 20, 2011 at 6:24 PM, Geoffrey Irving irv...@naml.us wrote:
Hello,
As a followup to the prior thread on bugs in user defined types in
numpy, I converted my rational number class from C++ to C and switched
to 32 bits to remove the need for unportable 128 bit numbers. It
should be
On Tue, Dec 20, 2011 at 10:48 PM, Christopher Jordan-Squire cjord...@uw.edu
wrote:
On Tue, Dec 20, 2011 at 9:10 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Dec 20, 2011 at 6:24 PM, Geoffrey Irving irv...@naml.us wrote:
Hello,
As a followup to the prior thread on bugs in user
On Tue, Jan 24, 2012 at 6:32 AM, Søren Gammelmark gammelm...@gmail.comwrote:
Dear all,
I was just looking into numpy.einsum and encountered an issue which might
be worth pointing out in the documentation.
Let us say you wish to evaluate something like this (repeated indices a
summed)
2012/1/21 Ondřej Čertík ondrej.cer...@gmail.com
snip
Let me know if you figure out something. I think the mask thing is
quite slow, but the problem is that it needs to be there, to catch
overflows (and it is there in Fortran as well, see the
where statement, which does the same thing).
On Tue, Jan 24, 2012 at 7:29 AM, Kathleen M Tacina
kathleen.m.tac...@nasa.gov wrote:
**
I was experimenting with np.min_scalar_type to make sure it worked as
expected, and found some unexpected results for integers between 2**63 and
2**64-1. I would have expected np.min_scalar_type(2**64-1)
On Mon, Jan 16, 2012 at 8:14 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Mon, Jan 16, 2012 at 8:52 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Jan 16, 2012 at 8:37 AM, Bruce Southey bsout...@gmail.comwrote:
**
On 01/14/2012 04:31 PM, Charles R Harris
On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris
charlesr.har...@gmail.comwrote:
The macro PyArray_RemoveLargest has been replaced by
PyArray_RemoveSmallest (which seems strange), but I wonder if this
documentation still makes sense.
My impression about this code is that it went through a
On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant tra...@continuum.io wrote:
On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
The macro PyArray_RemoveLargest has been replaced by
PyArray_RemoveSmallest (which
instead of to the left.
-Mark
-Travis
On Feb 1, 2012, at 8:31 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant tra...@continuum.iowrote:
On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris
charlesr.har...@gmail.com
On Wed, Feb 1, 2012 at 12:53 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
Hi All,
Two things here.
1) Some macros for threading and the iterator now require a trailing
semicolon. This change will be reverted before the 1.7 release so that
scipy 0.10 will compile, but because it
On Sat, Feb 4, 2012 at 8:07 AM, Ralf Gommers ralf.gomm...@googlemail.comwrote:
On Wed, Dec 28, 2011 at 2:58 PM, Ralf Gommers ralf.gomm...@googlemail.com
wrote:
Hi,
I'm having some trouble cleaning up tests to deal with these two
deprecations:
DeprecationWarning: Setting NumPy dtype
Hey John,
NumPy doesn't provide this, because it's already provided by the
datetime.date.strftime function in Python:
http://docs.python.org/library/datetime.html#datetime.date.strftime
One reason this format isn't supported automatically is that parsing
MM/dd/YY is inherently ambiguous, and
Converting between date and datetime requires caution, because it depends
on your time zone. Because all datetime64's are internally stored in UTC,
simply casting as in your example treats it in UTC. The 'astype' function
does not raise an error to tell you that this is problematic, because
On Sat, Feb 11, 2012 at 3:27 PM, mark florisson
markflorisso...@gmail.comwrote:
On 11 February 2012 20:31, Charles R Harris charlesr.har...@gmail.com
wrote:
Hi Dag,
This probably needs to be on the cython mailing list at some point, but I
thought I'd start the discussion here. Numpy is
On Sat, Feb 11, 2012 at 3:12 PM, Eric Firing efir...@hawaii.edu wrote:
On 02/11/2012 10:44 AM, Travis Oliphant wrote:snip
2) You must be an admin to label an issue (i.e. set it as a bug,
enhancement, or so forth).
A third problem is that the entire style of presentation is poorly
On Sat, Feb 11, 2012 at 2:13 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Sat, Feb 11, 2012 at 12:11 PM, Travis Oliphant tra...@continuum.iowrote:
I propose to give Francesc Alted commit rights to the NumPy project.
Francesc will be working full time on NumPy for several months
On Mon, Feb 13, 2012 at 5:00 PM, Travis Oliphant tra...@continuum.iowrote:
Hmmm. This seems like a regression. The scalar casting API was fairly
intentional.
What is the reason for the change?
In order to make 1.6 ABI-compatible with 1.5, I basically had to rewrite
this subsystem. There
It might be nice to turn the matrix class into a short class hierarchy,
something like this:
class MatrixBase
class DenseMatrix(MatrixBase)
class TriangularMatrix(MatrixBase) # Maybe a few variations of upper/lower
triangular and whether the diagonal is stored
class SymmetricMatrix(MatrixBase)
I took a look into the code to see what is causing this, and the reason is
that nothing has ever been implemented to deal with the fields. This means
it falls back to treating all struct dtypes as if they were a plain void
dtype, which allows anything to be cast to it.
While I was redoing the
, at 7:58 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Mon, Feb 13, 2012 at 5:00 PM, Travis Oliphant tra...@continuum.iowrote:
Hmmm. This seems like a regression. The scalar casting API was fairly
intentional.
What is the reason for the change?
In order to make 1.6 ABI-compatible with 1.5
as anyone can give them.
It's great to have you back and active in the community again too. I'm sure
this is improving the moods of many NumPy and SciPy users.
-Mark
-Travis
On Feb 13, 2012, at 9:40 PM, Mark Wiebe wrote:
I believe the main lessons to draw from this are just how incredibly
On Mon, Feb 13, 2012 at 10:38 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Feb 13, 2012 at 11:07 PM, Travis Oliphant tra...@continuum.iowrote:
No argument on any of this. It's just that this needs to happen at
NumPy 2.0, not in the NumPy 1.X series. I think
On Mon, Feb 13, 2012 at 10:48 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Mon, Feb 13, 2012 at 10:38 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Feb 13, 2012 at 11:07 PM, Travis Oliphant tra...@continuum.iowrote:
No argument on any of this. It's just
will be working on NumPy 1.8 (me,
Francesc Alted, and Bryan Van de Ven). Mark Wiebe is slated to help us, as
well, but I would like to sponsor him as much as possible on the work for
NumPy 2.0.If anyone else would like to join us, please let me know
off-list. There is room for another talented
On Tue, Feb 14, 2012 at 12:27 PM, Benjamin Root ben.r...@ou.edu wrote:
On Tuesday, February 14, 2012, Travis Oliphant tra...@continuum.io
wrote:
As you can see there were changes in each release. Most of these
were minor prior to the change from 1.5.1 to 1.6.1. I am still reviewing
the
On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe mwwi...@gmail.com wrote:
I took a look into the code to see what is causing this, and the reason
is
that nothing has ever been implemented to deal with the fields
On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root ben.r...@ou.edu wrote:
Just a thought I had. Right now, I can pass a list of python ints or
floats into np.array() and get a numpy array with a sensible dtype. Is
there any reason why we can't do the same for python's datetime? Right
now, it
On Tue, Feb 14, 2012 at 9:37 PM, Benjamin Root ben.r...@ou.edu wrote:
On Tuesday, February 14, 2012, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root ben.r...@ou.edu wrote:
Just a thought I had. Right now, I can pass a list of python ints or
floats
On Wed, Feb 15, 2012 at 12:09 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Wed, Feb 15, 2012 at 11:46 AM, Benjamin Root ben.r...@ou.edu wrote:
On Wed, Feb 15, 2012 at 1:32 PM, Alan G Isaac alan.is...@gmail.com
wrote:
Can you provide an example where a more formal
On Wed, Feb 15, 2012 at 1:36 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Wed, Feb 15, 2012 at 12:55 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Feb 15, 2012 at 12:09 PM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Wed, Feb 15, 2012 at 11:46 AM, Benjamin
On Wed, Feb 15, 2012 at 4:57 PM, josef.p...@gmail.com wrote:
On Wed, Feb 15, 2012 at 7:27 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 02/15/2012 02:24 PM, Mark Wiebe wrote:
On Wed, Feb 15, 2012 at 1:36 PM, Matthew Brett matthew.br...@gmail.com
mailto:matthew.br
, Travis Oliphant tra...@continuum.io
wrote:
Mark Wiebe and I have been discussing off and on (as well as talking
with Charles) a good way forward to balance two competing desires:
* addition of new features that are needed in NumPy
* improving the code-base generally
, Travis Oliphant
tra...@continuum.io mailto:tra...@continuum.io wrote:
Mark Wiebe and I have been discussing off and on (as well as
talking with Charles) a good way forward to balance two competing
desires:
* addition of new features that are needed
On Fri, Feb 17, 2012 at 11:00 AM, Christopher Jordan-Squire cjord...@uw.edu
wrote:
On Fri, Feb 17, 2012 at 10:21 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Fri, Feb 17, 2012 at 11:52 AM, Eric Firing efir...@hawaii.edu
wrote:
On 02/17/2012 05:39 AM, Charles R Harris wrote:
On Fri
warren.weckes...@enthought.com wrote:
On Thu, Feb 16, 2012 at 4:39 PM, Travis Oliphant tra...@continuum.io
wrote:
Mark Wiebe and I have been discussing off and on (as well as talking
with
Charles) a good way forward to balance two competing desires:
* addition of new features
The suggestion of transitioning the NumPy core code from C to C++ has
sparked a vigorous debate, and I thought I'd start a new thread to give my
perspective on some of the issues raised, and describe how such a
transition could occur.
First, I'd like to reiterate the gcc rationale for their
On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau courn...@gmail.comwrote:
On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Well, we already have code obfuscation (DOUBLE_your_pleasure,
FLOAT_your_boat), so we might as well let the compiler handle it.
On Sun, Feb 19, 2012 at 2:24 AM, Stéfan van der Walt ste...@sun.ac.zawrote:
Hey, Mark
On Feb 18, 2012 11:18 PM, Mark Wiebe mwwi...@gmail.com wrote:
My experience has been that providing a C API from a C++ library is no
harder than providing a C API from a C library.
Interfacing
On Sun, Feb 19, 2012 at 2:32 AM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
Thanks for this - it's very helpful.
On Sat, Feb 18, 2012 at 11:18 PM, Mark Wiebe mwwi...@gmail.com wrote:
The suggestion of transitioning the NumPy core code from C to C++ has
sparked a vigorous debate
On Sun, Feb 19, 2012 at 2:51 AM, Stéfan van der Walt ste...@sun.ac.zawrote:
On Feb 19, 2012 12:34 AM, Mark Wiebe mwwi...@gmail.com wrote:
I'm speaking from personal experience having dealt with these types of
issues extensively before. If people have more detailed examples of
problems
On Sun, Feb 19, 2012 at 2:56 AM, David Cournapeau courn...@gmail.comwrote:
Hi Mark,
thank you for joining this discussion.
On Sun, Feb 19, 2012 at 7:18 AM, Mark Wiebe mwwi...@gmail.com wrote:
The suggestion of transitioning the NumPy core code from C to C++ has
sparked a vigorous debate
On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau courn...@gmail.comwrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau courn...@gmail.com
wrote:
On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
charlesr.har
On Sun, Feb 19, 2012 at 3:10 AM, Matthew Brett matthew.br...@gmail.comwrote:
snip
As you probably saw, I think the proposal was indeed to use Cython to
provide the higher-level parts of the core, while refactoring the rest
of the C code underneath it. Obviously one could also refactor the C
On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh ben_w_...@yahoo.co.uk wrote:
Date: Sun, 19 Feb 2012 01:18:20 -0600
From: Mark Wiebe mwwi...@gmail.com
Subject: [Numpy-discussion] How a transition to C++ could work
To: Discussion of Numerical Python NumPy-Discussion@scipy.org
Message-ID
On Sun, Feb 19, 2012 at 3:45 AM, David Cournapeau courn...@gmail.comwrote:
On Sun, Feb 19, 2012 at 9:19 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Feb 19, 2012 at 2:56 AM, David Cournapeau courn...@gmail.com
wrote:
Hi Mark,
thank you for joining this discussion.
On Sun, Feb
On Sun, Feb 19, 2012 at 4:14 AM, David Cournapeau courn...@gmail.comwrote:
On Sun, Feb 19, 2012 at 9:52 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh ben_w_...@yahoo.co.uk
wrote:
Date: Sun, 19 Feb 2012 01:18:20 -0600
From: Mark Wiebe mwwi
On Sun, Feb 19, 2012 at 4:30 AM, Christopher Jordan-Squire
cjord...@uw.eduwrote:
On Sun, Feb 19, 2012 at 2:14 AM, David Cournapeau courn...@gmail.com
wrote:
On Sun, Feb 19, 2012 at 9:52 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh ben_w_...@yahoo.co.uk
On Sun, Feb 19, 2012 at 5:25 AM, Nathaniel Smith n...@pobox.com wrote:
On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau courn...@gmail.com
wrote:
On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe mwwi...@gmail.com wrote:
Is there a specific
target platform/compiler combination you're thinking
On Sun, Feb 19, 2012 at 4:03 AM, David Cournapeau courn...@gmail.comwrote:
On Sun, Feb 19, 2012 at 9:28 AM, Mark Wiebe mwwi...@gmail.com wrote:
Is there anyone who uses a blue gene or small device which needs
up-to-date
numpy support, that I could talk to directly? We really need a list
On Sun, Feb 19, 2012 at 7:35 AM, Pauli Virtanen p...@iki.fi wrote:
19.02.2012 05:38, Travis Oliphant kirjoitti:
[clip]
Sure. This list actually deserves a long writeup about that.
First, there wasn't a Cython-refactor of NumPy. There was a
Cython-refactor of SciPy. I'm not sure of
On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
pierre.haes...@crans.org wrote:
Le 23/02/2012 17:28, Charles R Harris a écrit :
That's correct. They are both extended precision (80 bits), but
aligned on
On Thu, Feb 23, 2012 at 10:55 AM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre
On Tue, Feb 28, 2012 at 11:03 PM, Fernando Perez fperez@gmail.comwrote:
On Tue, Feb 28, 2012 at 10:46 PM, Travis Oliphant tra...@continuum.io
wrote:
We already use the NEP process for such decisions. This discussion
came from simply from the *idea* of writing such a NEP.
Nothing
of
untestable commits. df907e6 is the first known bad. Here's the
output from a log:
* df907e6 - (HEAD, refs/bisect/bad) BLD: Failure in single file build
mode because of a static function in two separate files (6 months ago)
[Mark Wiebe]
* 01b200b - (refs/bisect/skip
On Sun, Mar 4, 2012 at 10:08 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Sun, Mar 4, 2012 at 11:41 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sun, Mar 4, 2012 at 11:27 AM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Sat, Mar 3, 2012 at 12:07 AM, Matthew Brett
On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett matthew.br...@gmail.comwrote:
snip
$ export NPY_SEPARATE_COMPILATION=1
Thanks, that did it:
9194b3af704df71aa9b1ff2f53f169848d0f9dc7 is the first bad commit
Let me know if I can debug further,
That commit was a rewrite of np.concatenate,
I've pushed a bugfix to github, can you confirm that the crash goes away on
your test box? Thanks for tracking that down, the stack trace was very
helpful. Since x86 machines don't have as strict alignment requirements,
bugs like this one will generally remain undetected until someone tests on
an
:
Le 03/03/2012 22:46, Mark Wiebe a écrit :
Also, here's a thought for the usability of NA-float64. As much as
global state is a bad idea, something which determines whether
implicit float dtypes are NA-float64 or float64 could help. In
IPython, pylab mode would default to float64, and statlab
On Fri, Mar 9, 2012 at 8:55 AM, Bryan Van de Ven bry...@continuum.iowrote:
Hi all,
I have started working on a NEP for adding an enumerated type to NumPy.
It is on my GitHub:
https://github.com/bryevdv/numpy/blob/enum/doc/neps/enum.rst
It is still very rough, and incomplete in places.
I've done some comparisons of 1.6.1 and 1.7 (master), and written up some
key differences in a pull request here:
https://github.com/numpy/numpy/pull/264/files#diff-0
What you've discovered here looks like an interaction between the automatic
unit detection and struct dtypes, it's a bug to do
On Mon, Apr 30, 2012 at 4:11 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Mon, Apr 30, 2012 at 1:19 PM, Mark Wiebe mwwi...@gmail.com wrote:
I've done some comparisons of 1.6.1 and 1.7 (master), and written up some
key differences in a pull request here:
https://github.com
On Sat, May 5, 2012 at 11:55 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft
aldcr...@head.cfa.harvard.edu wrote:
On Fri, May 4, 2012 at 11:44 PM, Ilan Schnell ischn...@enthought.com
wrote:
Hi Chuck,
thanks for the prompt reply. I
On Sat, May 5, 2012 at 1:06 PM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Sat, May 5, 2012 at 11:55 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Sat, May 5, 2012 at 5:27 AM, Tom Aldcroft
aldcr
On Wed, May 9, 2012 at 11:46 AM, Travis Oliphant tra...@continuum.iowrote:
Hey all,
Nathaniel and Mark have worked very hard on a joint document to try and
explain the current status of the missing-data debate. I think they've
done an amazing job at providing some context, articulating
On Wed, May 9, 2012 at 2:15 PM, Travis Oliphant tra...@continuum.io wrote:
On May 9, 2012, at 2:07 PM, Mark Wiebe wrote:
On Wed, May 9, 2012 at 11:46 AM, Travis Oliphant tra...@continuum.iowrote:
Hey all,
Nathaniel and Mark have worked very hard on a joint document to try and
explain
On Thu, May 10, 2012 at 5:27 PM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 05/10/2012 08:23 PM, Chris Barker wrote:
On Thu, May 10, 2012 at 2:38 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
What would serve me? I use NumPy as a glorified double*.
all I
On Fri, May 11, 2012 at 6:13 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
(NumPy devs: I know, I get too many ideas. But this time I *really*
believe in it, I think this is going to be *huge*. And if Mark F. likes
it it's not going to be without manpower; and as his mentor I'd
On Fri, May 11, 2012 at 2:18 PM, Pauli Virtanen p...@iki.fi wrote:
11.05.2012 17:54, Frédéric Bastien kirjoitti:
In Theano we use a view, but that is not relevant as it is the
compiler that tell what is inplace. So this is invisible to the user.
What about a parameter to diagonal() that
On Fri, May 11, 2012 at 8:37 AM, mark florisson
markflorisso...@gmail.comwrote:
On 11 May 2012 12:13, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no
wrote:
(NumPy devs: I know, I get too many ideas. But this time I *really*
believe
in it, I think this is going to be *huge*. And if Mark F.
On Thu, May 10, 2012 at 10:28 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Thu, May 10, 2012 at 2:43 AM, Nathaniel Smith n...@pobox.com wrote:
Hi Matthew,
On Thu, May 10, 2012 at 12:01 AM, Matthew Brett matthew.br...@gmail.com
wrote:
The third proposal is certainly the best
On Tue, Jun 5, 2012 at 5:40 AM, Nathaniel Smith n...@pobox.com wrote:
On Tue, Jun 5, 2012 at 11:06 AM, Thouis (Ray) Jones wrote:
All of the failing tests seem to have been caused by the buffer copy
bug, fixed in https://github.com/mwiebe/numpy/tree/nditer_buffer_flag(but
not yet pulled
On Fri, Aug 31, 2012 at 5:35 PM, Ondřej Čertík ondrej.cer...@gmail.comwrote:
Hi Dag,
On Fri, Aug 31, 2012 at 4:22 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no wrote:
On 08/31/2012 09:03 AM, Ondřej Čertík wrote:
Hi,
There is segfault reported here:
I've tracked down and fixed a memory leak in 1.7 and master. The pull
request to check and backport is here:
https://github.com/numpy/numpy/pull/2928
Thanks,
Mark
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing efir...@hawaii.edu wrote:
On 2013/01/17 4:13 AM, Pierre Haessig wrote:
Hi,
Le 14/01/2013 20:05, Benjamin Root a écrit :
I do like the way you are thinking in terms of
On Wed, Apr 3, 2013 at 9:33 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
dave.hirschf...@gmail.com wrote:
I found no reasonable way around it other than bypassing the numpy
conversion entirely
Exactly - we have come to the same conclusion. By the way, it's also
consistent
On Mon, Apr 8, 2013 at 12:24 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Recent discussion has made it clear that the timezone handling in the
current (numpy1.7) version of datetime64 is broken. Below is a
discussion of some possible solutions, hopefully including most of the
On Wed, Jun 19, 2013 at 7:48 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Wed, Jun 19, 2013 at 5:45 AM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Wed, Jun 19, 2013 at 1:43 AM, Frédéric Bastien no...@nouiz.org
wrote:
Hi,
On Mon, Jun 17, 2013 at 5:03 PM, Julian
On Wed, Aug 14, 2013 at 9:00 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Tue, Aug 13, 2013 at 5:54 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
I wish it were. It seems unreasonably difficult to get constructive
feedback. Chris is pretty much the only one
I found a bug in structured array comparison when fields have
multi-dimensional types. I created a ticket here:
http://projects.scipy.org/numpy/ticket/1640
and a patch here:
http://github.com/m-paradox/numpy/compare/master...fix_structured_compare
Could someone review it for me?
Thanks,
Mark
On Tue, Oct 19, 2010 at 12:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
snip
We're still working things out after the move, so you get to be sort of a
guinea pig ;) I think a pull request is the way to go.
Sounds good. :)
snip
You can request a pull of the branch. Just
What about this as a possibility:
numpy.intp(0).itemsize == 8
True
-Mark
On Tue, Oct 19, 2010 at 7:11 PM, Vincent Davis vinc...@vincentdavis.netwrote:
A little followup from the python list. I thought this was worth sharing
here.
Quoting Ned Deily, n...@acm.org
It looks better but
It turns out that when comparing dtypes, the subarray is currently ignored.
This means you can get things like this:
import numpy as np
np.dtype(('f4',(6))) == np.dtype(('f4',(2,3)))
True
np.dtype(([('a','i4')],2)) == np.dtype(([('b','u2'),('c','i2')],2))
True
which pretty clearly should be
snip
The other issue of allowing broadcasting in sub-arrays --- it does not
seem very useful to me. Unlike arrays, the dimensions of sub-arrays
cannot be manipulated easily, and so many use-cases of broadcasting just
disappear.
I implemented the a/b shape checking in the structured array
On Thu, Oct 21, 2010 at 1:06 PM, Pauli Virtanen p...@iki.fi wrote:
snip
It seems that `_void_compare` *must* handle broadcasting itself -- I
thought this was done by the caller, but apparently not. So you're right
that the correct place to do the shape check is on the dtype level.
There's a
On Thu, Oct 21, 2010 at 2:11 PM, Pauli Virtanen p...@iki.fi wrote:
snip
Also, it is not correct to assume the dimensions are added to the end:
x = np.zeros((2,3),dtype=[('a','f8',(4,))]).T
x.shape
(3, 2)
x['a'].shape
(4, 3, 2)
There's a special branch in the field access code that
On Thu, Oct 21, 2010 at 2:47 PM, Pauli Virtanen p...@iki.fi wrote:
Thu, 21 Oct 2010 14:25:24 -0700, Mark Wiebe wrote:
[clip]
That sounds like it could be tricky to handle correctly, especially
since it should probably work to compare Fortran-order arrays with
non-Fortran ones.
Does
Because writing arr.ravel('F') doesn't seem as descriptive as
arr.ravel(order='F'), I wrote this simple patch. I added mention of the
order='A' parameter to a few places it is relevant as well. Here's the
branch on github:
http://github.com/m-paradox/numpy/compare/master...ravel_keyword_arg
I wrote a float16/half-precision module here:
https://github.com/m-paradox/numpy_half
I've tested it with NumPy 1.3.0 and the latest trunk. With it, you can do
things like this:
import numpy as np, half as h
np.array([0,0.1,1.0/3.0], dtype='float16')
array([ 0., 0.09997559,
This set of patches fully implements a 16-bit floating point half type into
NumPy. It's got a lot of changes, but I've tried to organize them logically
so that it builds and the tests run after each patch. This took some tweaks
to the building and ufunc generation code, so please check that, as
On Sat, Nov 13, 2010 at 6:41 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
Hi All,
This is in reference to numpy ticket
#1671http://projects.scipy.org/numpy/ticket/1671and the comments on pull
request 13 https://github.com/numpy/numpy/pull/13. The original problem
was that the gcc
On Sun, Nov 14, 2010 at 7:07 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
Another possible solution is like so:
static __attribute__ ((noinline)) int
fpecheck(int *status)
{
*status = PyUFunc_getfperr();
return 0;
}
static __attribute__ ((noinline)) int
fpeclear(int
On Sun, Nov 14, 2010 at 12:21 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
Good point. I was trying to keep the fpeclear in front of the code to be
tested.
Yeah, I hadn't considered that possibility too seriously. Hopefully as long
as the compiler doesn't see a reason to reorder,
I've created a ticket and a pull request for the half-float type I
implemented. Since my previous email, I've moved the half implementation
into npymath so modules using numpy can do half-float code as well. There
are a few key things that in my mind should get some discussion before
saying this
On Thu, Dec 2, 2010 at 10:16 AM, Pauli Virtanen p...@iki.fi wrote:
Before introducing a PEP 3118 type code for half floats in the PEP, one
would need to argue the Python people to add it to the struct module.
Before that, the choices probably are:
- refuse to export buffers containing half
On Sat, Dec 4, 2010 at 12:45 PM, Pauli Virtanen p...@iki.fi wrote:
Technically, the move could be done like this, so that merge tracking
still works:
refactor--- new-refactor
//
/libndarray--x
Hello NumPy-ers,
After some performance analysis, I've designed and implemented a new
iterator designed to speed up ufuncs and allow for easier multi-dimensional
iteration. The new code is fairly large, but works quite well already. If
some people could read the NEP and give some feedback, that
1 - 100 of 444 matches
Mail list logo
