On Wed, Oct 7, 2015 at 12:59 PM, Matti Picus wrote:
> I am trying to understand how nditer(ops, order='K') handles C and F
> order. In the documentation it states
> "‘K’ means as close to the order the array elements appear in memory as
> possible"
> but I seem to be getting inconsistent results
On Wed, Aug 26, 2015 at 10:11 AM, Antoine Pitrou
wrote:
> On Wed, 26 Aug 2015 16:45:51 + (UTC)
> Irwin Zaid wrote:
> >
> > So, we see DyND is having a twofold purpose. The first is to expand upon
> the
> > kinds of data that NumPy can represent and do computations upon. The
> second
> > is t
I thought I'd add a little more specifically about the kind of
graphics/point cloud work I'm doing right now at Thinkbox, and how it
relates. To echo Francesc's point about NumPy already being an industry
standard, within the VFX/graphics industry there is a reference platform
definition on Linux,
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
> wrote:
> > I wish it were. It seems unreasonably difficult to get constructive
> > feedback. Chris is pretty much the only one making the attempt and
On Wed, Jun 19, 2013 at 7:48 AM, Charles R Harris wrote:
>
>
> On Wed, Jun 19, 2013 at 5:45 AM, Matthew Brett wrote:
>
>> Hi,
>>
>> On Wed, Jun 19, 2013 at 1:43 AM, Frédéric Bastien
>> wrote:
>> > Hi,
>> >
>> >
>> > On Mon, Jun 17, 2013 at 5:03 PM, Julian Taylor
>> > wrote:
>> >>
>> >> On 17.06
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
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen wrote:
> Mark Wiebe gmail.com> writes:
> > It seems to me that adding a time zone to the datetime64
> > metadata might be a good idea, and then allowing it to be
> > None to behave like the Python naive datetimes.
>
On Wed, Apr 3, 2013 at 9:33 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> 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 -- an ISO string
On Thu, Jan 17, 2013 at 2:10 PM, Benjamin Root wrote:
>
>
> On Thu, Jan 17, 2013 at 5:04 PM, Eric Firing 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 the broadcasting
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
http://mail.scipy.org/mailman
On Fri, Aug 31, 2012 at 5:35 PM, Ondřej Čertík wrote:
> Hi Dag,
>
> On Fri, Aug 31, 2012 at 4:22 AM, Dag Sverre Seljebotn
> wrote:
> > On 08/31/2012 09:03 AM, Ondřej Čertík wrote:
> >> Hi,
> >>
> >> There is segfault reported here:
> >>
> >> http://projects.scipy.org/numpy/ticket/1588
> >>
> >> I
On Tue, Jun 5, 2012 at 5:40 AM, Nathaniel Smith 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 into numpy).
On Sat, May 19, 2012 at 10:00 AM, David Cournapeau wrote:
> On Sat, May 19, 2012 at 3:17 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> On Fri, May 18, 2012 at 3:47 PM, Travis Oliphant wrote:
>>
>>> Hey all,
>>>
>>> After reading all the discussion around masked arrays and getting
On Thu, May 10, 2012 at 10:28 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, May 10, 2012 at 2:43 AM, Nathaniel Smith wrote:
> > Hi Matthew,
> >
> > On Thu, May 10, 2012 at 12:01 AM, Matthew Brett
> wrote:
> >>> The third proposal is certainly the best one from Cython's perspective;
> >>> and I imag
On Fri, May 11, 2012 at 8:37 AM, mark florisson
wrote:
> On 11 May 2012 12:13, Dag Sverre Seljebotn
> 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
On Fri, May 11, 2012 at 2:18 PM, Pauli Virtanen 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 def
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
On Thu, May 10, 2012 at 5:47 PM, Dag Sverre Seljebotn <
d.s.seljeb...@astro.uio.no> wrote:
> On 05/11/2012 12:28 AM, Mark Wiebe wrote:
> > I did some searching for typical Cython and C code which accesses numpy
> > arrays, and added a section to the NEP describing h
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
> > wrote:
> >> What would serve me? I use NumPy as a glorified "double*".
> >
> >> all I want is my
I did some searching for typical Cython and C code which accesses numpy
arrays, and added a section to the NEP describing how they behave in the
current implementation. Cython code which uses either straight Python
access or the buffer protocol is fine (after a bugfix in numpy, it wasn't
failing cu
On Wed, May 9, 2012 at 2:15 PM, Travis Oliphant wrote:
>
> On May 9, 2012, at 2:07 PM, Mark Wiebe wrote:
>
> On Wed, May 9, 2012 at 11:46 AM, Travis Oliphant wrote:
>
>> Hey all,
>>
>> Nathaniel and Mark have worked very hard on a joint document to try and
>
On Wed, May 9, 2012 at 11:46 AM, Travis Oliphant wrote:
> 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 their views and
>
On Sat, May 5, 2012 at 1:06 PM, Charles R Harris
wrote:
>
> On Sat, May 5, 2012 at 11:19 AM, Mark Wiebe 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
On Sat, May 5, 2012 at 11:55 AM, Charles R Harris 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
>> wrote:
>> > Hi Chuck,
>> >
>> > thanks for the prompt reply. I as curious because because
>
On Mon, Apr 30, 2012 at 4:11 PM, Charles R Harris wrote:
>
>
> On Mon, Apr 30, 2012 at 1:19 PM, Mark Wiebe 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://git
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 wit
On Fri, Mar 9, 2012 at 8:55 AM, Bryan Van de Ven wrote:
> 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. But I would
>
> 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,
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 a
On Sun, Mar 4, 2012 at 10:34 PM, Matthew Brett wrote:
>
> > $ 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, and I've traced the
On Sun, Mar 4, 2012 at 10:08 PM, Matthew Brett wrote:
> Hi,
>
> On Sun, Mar 4, 2012 at 11:41 AM, Mark Wiebe wrote:
> > On Sun, Mar 4, 2012 at 11:27 AM, Matthew Brett
> > wrote:
> >>
> >> Hi,
> >>
> >> On Sat, Mar 3, 2012 at 12:07 AM, Mat
;
> >>> This on current master : 1.7.0.dev-b9872b4
> >>>
> >>
> >> Hmm, some tests might have been recently enabled. Any chance of doing a
> >> bisection?
>
> Struggling because compilation is very slow and there are lots of
On Sat, Mar 3, 2012 at 12:30 PM, Travis Oliphant wrote:
>
>
> First of all, I want to be clear that I think there is much great work
> that has been done in the current missing data code. There are some nice
> features in the where clause of the ufunc and the machinery for the
> iterator that
On Tue, Feb 28, 2012 at 11:03 PM, Fernando Perez wrote:
> On Tue, Feb 28, 2012 at 10:46 PM, Travis Oliphant
> wrote:
> > We already use the NEP process for such decisions. This discussion
> came from simply from the *idea* of writing such a NEP.
> >
> > Nothing has been decided. Only opinions
On Thu, Feb 23, 2012 at 10:55 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe wrote:
> > On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Feb 23, 2012 at 10:1
On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
> 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 32bit/64bit boundaries respectively.
On Sun, Feb 19, 2012 at 7:35 AM, Pauli Virtanen 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 o
On Sun, Feb 19, 2012 at 4:03 AM, David Cournapeau wrote:
> On Sun, Feb 19, 2012 at 9:28 AM, Mark Wiebe 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 of
>
On Sun, Feb 19, 2012 at 5:25 AM, Nathaniel Smith wrote:
> On Sun, Feb 19, 2012 at 9:16 AM, David Cournapeau
> wrote:
> > On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote:
> >> Is there a specific
> >> target platform/compiler combination you're thinking of
On Sun, Feb 19, 2012 at 4:30 AM, Christopher Jordan-Squire
wrote:
> On Sun, Feb 19, 2012 at 2:14 AM, David Cournapeau
> wrote:
> > On Sun, Feb 19, 2012 at 9:52 AM, Mark Wiebe wrote:
> >> On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh
> wrote:
> >>>
> >>
On Sun, Feb 19, 2012 at 4:14 AM, David Cournapeau wrote:
> On Sun, Feb 19, 2012 at 9:52 AM, Mark Wiebe wrote:
> > On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh
> wrote:
> >>
> >>
> >>
> >> > Date: Sun, 19 Feb 2012 01:18:20 -0600
> >>
On Sun, Feb 19, 2012 at 3:45 AM, David Cournapeau wrote:
> On Sun, Feb 19, 2012 at 9:19 AM, Mark Wiebe wrote:
> > On Sun, Feb 19, 2012 at 2:56 AM, David Cournapeau
> > wrote:
> >>
> >> Hi Mark,
> >>
> >> thank you for joining this discussi
On Sun, Feb 19, 2012 at 3:10 AM, Ben Walsh wrote:
>
>
> > Date: Sun, 19 Feb 2012 01:18:20 -0600
> > From: Mark Wiebe
> > Subject: [Numpy-discussion] How a transition to C++ could work
> > To: Discussion of Numerical Python
> > Message-ID:
> >
On Sun, Feb 19, 2012 at 3:10 AM, Matthew Brett wrote:
>
> 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
> into C++, so the propo
On Sun, Feb 19, 2012 at 3:16 AM, David Cournapeau wrote:
> On Sun, Feb 19, 2012 at 8:08 AM, Mark Wiebe wrote:
> > On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau
> > wrote:
> >>
> >> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
> >> wrote:
>
On Sun, Feb 19, 2012 at 2:56 AM, David Cournapeau wrote:
> Hi Mark,
>
> thank you for joining this discussion.
>
> On Sun, Feb 19, 2012 at 7:18 AM, Mark Wiebe 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 wrote:
>
> On Feb 19, 2012 12:34 AM, "Mark Wiebe" wrote:
> >
> > I'm speaking from personal experience having dealt with these types of
> issues extensively before. If people have more detailed examp
On Sun, Feb 19, 2012 at 2:32 AM, Matthew Brett wrote:
> Hi,
>
> Thanks for this - it's very helpful.
>
> On Sat, Feb 18, 2012 at 11:18 PM, Mark Wiebe wrote:
> > The suggestion of transitioning the NumPy core code from C to C++ has
> > sparked a vigorous debat
On Sun, Feb 19, 2012 at 2:24 AM, Stéfan van der Walt wrote:
> Hey, Mark
>
> On Feb 18, 2012 11:18 PM, "Mark Wiebe" 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.
>
> Interfac
On Sat, Feb 18, 2012 at 4:24 PM, David Cournapeau wrote:
> On Sat, Feb 18, 2012 at 9:40 PM, Charles R Harris
> wrote:
>
> >
> > Well, we already have code obfuscation (DOUBLE_your_pleasure,
> > FLOAT_your_boat), so we might as well let the compiler handle it.
>
> Yes, those are not great, but on
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 choice
Warren Weckesser
>>> wrote:
>>> >
>>> >
>>> > On Thu, Feb 16, 2012 at 4:39 PM, Travis Oliphant
>>> > wrote:
>>> >>
>>> >> Mark Wiebe and I have been discussing off and on (as well as talking
>>&
On Fri, Feb 17, 2012 at 11:00 AM, Christopher Jordan-Squire wrote:
> On Fri, Feb 17, 2012 at 10:21 AM, Mark Wiebe wrote:
> > On Fri, Feb 17, 2012 at 11:52 AM, Eric Firing
> wrote:
> >>
> >> On 02/17/2012 05:39 AM, Charles R Harris wrote:
> >> >
>
gt; On Thu, Feb 16, 2012 at 10:39 PM, Travis Oliphant
> > 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
> >
> On Thu, Feb 16, 2012 at 10:39 PM, Travis Oliphant
> >> 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:
> >> >
> >> >* ad
On Wed, Feb 15, 2012 at 4:57 PM, wrote:
> On Wed, Feb 15, 2012 at 7:27 PM, Dag Sverre Seljebotn
> wrote:
> > On 02/15/2012 02:24 PM, Mark Wiebe wrote:
> >> On Wed, Feb 15, 2012 at 1:36 PM, Matthew Brett >> <mailto:matthew.br...@gmail.com>> wrote:
> >&
On Wed, Feb 15, 2012 at 1:36 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Feb 15, 2012 at 12:55 PM, Mark Wiebe wrote:
> > On Wed, Feb 15, 2012 at 12:09 PM, Matthew Brett >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Feb 15, 2012 at 11:46
On Wed, Feb 15, 2012 at 12:09 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Feb 15, 2012 at 11:46 AM, Benjamin Root wrote:
> >
> >
> > On Wed, Feb 15, 2012 at 1:32 PM, Alan G Isaac
> wrote:
> >> Can you provide an example where a more formal
> >> governance structure for NumPy would have meant
> >>
On Tue, Feb 14, 2012 at 9:37 PM, Benjamin Root wrote:
> On Tuesday, February 14, 2012, Mark Wiebe wrote:
> > On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root wrote:
> >>
> >> Just a thought I had. Right now, I can pass a list of python ints or
> floats into np.arra
On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root 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 is very easy
On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett wrote:
> Hi,
>
> On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe 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. This
&
On Tue, Feb 14, 2012 at 12:27 PM, Benjamin Root wrote:
>
>
> On Tuesday, February 14, 2012, Travis Oliphant
> 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 changes from 1.5.1 to 1.
a tentative target for NumPy 1.8 in June/July.So
> far, there are three developers who 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
> Nu
On Mon, Feb 13, 2012 at 10:48 PM, Mark Wiebe 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 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 wrote:
>
>>
>> >
>>> > 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 requiring
ree that Rolf and Charles
> have-been and are invaluable in the maintenance and progress of NumPy and
> SciPy. They deserve as much praise and kudos 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 mo
to do that.
>
> Thanks,
>
> Travis
>
> --
> Travis Oliphant
> (on a mobile)
> 512-826-7480
>
>
> On Feb 13, 2012, at 7:58 PM, Mark Wiebe wrote:
>
> On Mon, Feb 13, 2012 at 5:00 PM, Travis Oliphant wrote:
>
>> Hmmm. This seems like a regressi
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 ca
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)
Th
On Mon, Feb 13, 2012 at 5:00 PM, Travis Oliphant wrote:
> 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 were virtually
On Sat, Feb 11, 2012 at 2:13 PM, Charles R Harris wrote:
>
> On Sat, Feb 11, 2012 at 12:11 PM, Travis Oliphant wrote:
>
>> I propose to give Francesc Alted commit rights to the NumPy project.
>> Francesc will be working full time on NumPy for several months and it will
>> enable him to participat
On Sat, Feb 11, 2012 at 3:12 PM, Eric Firing wrote:
> On 02/11/2012 10:44 AM, Travis Oliphant wrote:
>
> > 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
> designed from a use
On Sat, Feb 11, 2012 at 3:27 PM, mark florisson
wrote:
> On 11 February 2012 20:31, Charles R Harris
> 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 going to begin
> deprecating
> > direct a
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
NumPy's
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 t
On Sat, Feb 4, 2012 at 8:07 AM, Ralf Gommers wrote:
>
>
> On Wed, Dec 28, 2011 at 2:58 PM, Ralf Gommers > wrote:
>
>> Hi,
>>
>> I'm having some trouble cleaning up tests to deal with these two
>> deprecations:
>>
>> DeprecationWarning: Setting NumPy dtype names is deprecated, the dtype
>> will be
On Wed, Feb 1, 2012 at 12:53 PM, Charles R Harris 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 is desirable in the l
The only notable difference from broadcasting was
that threading adds axis padding to the right 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 wrote:
>
>>
On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant 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
>>
On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris
wrote:
> 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 number of rounds
trying
On Mon, Jan 16, 2012 at 8:14 AM, Charles R Harris 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 wrote:
>>
>>> **
>>> On 01/14/2012 04:31 PM, Charles R Harris wrote:
>>>
>>> I've put up
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**
2012/1/21 Ondřej Čertík
>
>
> 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). Maybe there is some
>
On Tue, Jan 24, 2012 at 6:32 AM, Søren Gammelmark wrote:
> 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)
>
> D[alpha, alphap
On Tue, Dec 20, 2011 at 10:48 PM, Christopher Jordan-Squire wrote:
> On Tue, Dec 20, 2011 at 9:10 PM, Mark Wiebe wrote:
> > On Tue, Dec 20, 2011 at 6:24 PM, Geoffrey Irving wrote:
> >>
> >> Hello,
> >>
> >> As a followup to the prior thread o
On Tue, Dec 20, 2011 at 6:24 PM, Geoffrey Irving 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 usable a
On Sat, Dec 3, 2011 at 6:18 PM, Travis Oliphant wrote:
>
> 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 smaller bunch
On Mon, Dec 5, 2011 at 9:37 AM, mark florisson wrote:
> On 5 December 2011 17:25, Mark Wiebe wrote:
> > On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving wrote:
> >>
> >>
> >>
> >>
> >> Back to the bugs: here's a branch with all t
On Mon, Dec 5, 2011 at 8:58 AM, David Cournapeau wrote:
> On Sun, Dec 4, 2011 at 9:45 PM, Charles R Harris
> 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 having some user
> > types in numpy.
On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving wrote:
>
>
> 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 bug, and an
113 118]]
[[ 64 69 74 79]
[ 84 89 94 99]
[104 109 114 119]]
Cheers,
Mark
>
>
> On Fri, Sep 30, 2011 at 5:04 PM, Mark Wiebe wrote:
>
>> On Fri, Sep 30, 2011 at 8:03 AM, John Salvatier <
>> jsalv...@u.washington.edu> wrote:
>>
>>> Using nditer, i
On Fri, Sep 30, 2011 at 8:03 AM, John Salvatier
wrote:
> Using nditer, is it possible to manually handle dimensions with different
> lengths?
>
> For example, lets say I had an array A[5, 100] and I wanted to sample every
> 10 along the second axis so I would end up with an array B[5,10]. Is it
>
On Sun, Sep 18, 2011 at 8:52 PM, wrote:
> On Sun, Sep 18, 2011 at 11:13 PM, Charles R Harris
> wrote:
> >
> >
> > On Sun, Sep 18, 2011 at 9:08 PM, Charles R Harris
> > wrote:
> >>
> >>
> >> On Sun, Sep 18, 2011 at 6:32 PM, Benjamin Root wrote:
> >>>
> >>> I was working on adding some test case
On Tue, Sep 20, 2011 at 8:38 AM, Sean Poust wrote:
> I keep getting this error: #warning "Using deprecated NumPy
> API, disable it by #defining NPY_NO_DEPRECATED_API" and a bunch of
> undefined variables when comping cython code with numpy
>
This is a warning introduced in current NumPy master.
On Fri, Sep 23, 2011 at 1:52 PM, Olivier Delalleau wrote:
> NB: I opened a ticket (http://projects.scipy.org/numpy/ticket/1949) about
> this, in case it would help getting some attention on this issue.
>
A lot of what you're seeing here is due to changes I did for 1.6. I
generally made the casti
2011/9/29 Grové
>
> Hi Mark
>
> Did you ever get to write:
>
> date_as_datetime(datearray, hour, minute, second, microsecond,
> timezone='local', unit=None, out=None)
> and
> datetime_as_date(datetimearray, timezone='local', out=None)
> ?
>
I never got to these functions, no.
I am looking for a
Probably has something to do with 'arr' having a statically defined type of
cnp.ndarray.
-Mark
On Thu, Sep 8, 2011 at 12:59 PM, Ralf Gommers
wrote:
> Hi,
>
> There's a test failure in scipy/io/matlab/mio_utils that shows up with
> numpy master but not 1.5.1, see
> http://projects.scipy.org/scipy
On Sat, Aug 27, 2011 at 3:28 AM, David Cournapeau wrote:
> Hi there,
>
> I am finally at a stage where bento can do most of what numscons could
> do. I would rather avoid having 3 different set of build scripts
> (distutils+bento+numscons) to maintain in the long term, so I would
> favor removing
ark
>
> -Chris JS
>
> On Wed, Aug 24, 2011 at 7:08 PM, Mark Wiebe wrote:
> > I've added C-API documentation to the missingdata branch. The .rst file
> > (beware of the github rst parser though, it drops some of the content) is
> > here:
> >
> https://gi
I've written some introductory documentation for the NA-masked arrays. The
patch is here:
https://github.com/m-paradox/numpy/commit/227e39c34b0e5d9dfde2bbce054b5a8ac088fd64
This is approaching the end of what I will implement for NA masks at the
moment. I think the system is quite usable as is, t
1 - 100 of 468 matches
Mail list logo
