Neil Martinsen-Burrell skrev:
>
> The persistence of the idea that removing Numpy's legacy features will
> only be annoyance is inimical to the popularity of the whole Numpy
> project. [...] Once scientists have working codes it is more than an
> annoyance to have to change those codes. In so
--- On Thu, 8/27/09, Johan Grönqvist wrote:
> If the proposed changes seem important, I would appreciate
> having a
> namespace called numpy.legacy or numpy.deprecated or
> numpy.1dotX, that
> retains all the old functions. That would only be a small
> annoyance (to
> me) if importing the righ
> Neil Martinsen-Burrell skrev:
>> The persistence of the idea that removing Numpy's legacy features will
>> only be annoyance is inimical to the popularity of the whole Numpy
>> project. [...] Once scientists have working codes it is more than an
>> annoyance to have to change those codes. In
Robert Kern wrote:
> On Thu, Aug 27, 2009 at 14:22, Christopher Barker
> wrote:
>
>> By the way -- is there something about py3k that changes all this? Or is
>> this just an opportunity to perhaps make some backward-incompatible
>> changes to numpy?
>
> Python 3 makes the promised change of int/
Hi,
Has someone written a fortran reader for the "npy" binary files numpy.save
creates ?
Thanks,
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
> Robert Kern wrote:
>
>> On Thu, Aug 27, 2009 at 14:22, Christopher
>> Barker wrote:
>>
>>> By the way -- is there something about py3k that changes all this? Or
>>> is this just an opportunity to perhaps make some backward-incompatible
>>
On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanen wrote:
> Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
>
>> Robert Kern wrote:
>>
>>> On Thu, Aug 27, 2009 at 14:22, Christopher
>>> Barker wrote:
>>>
By the way -- is there something about py3k that changes all this? Or
is this ju
On Fri, Aug 28, 2009 at 8:08 AM, wrote:
> On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanen wrote:
> > Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
> >
> >> Robert Kern wrote:
> >>
> >>> On Thu, Aug 27, 2009 at 14:22, Christopher
> >>> Barker wrote:
> >>>
> By the way -- is there so
Charles R Harris wrote:
> On Fri, Aug 28, 2009 at 8:08 AM, wrote:
>
>> On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanen wrote:
>> > Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
>> >
>> >> Robert Kern wrote:
>> >>
>> >>> On Thu, Aug 27, 2009 at 14:22, Christopher
>> >>> Barker wrote:
>>
On 8/28/2009 10:46 AM Neal Becker apparently wrote:
> explicit is better than implicit. IMO, if I want int/int-> float, I should
> ask for it explicitly, by casting the ints to float first (in numpy, that
> would be using astype).
Aren't you begging the question?
Nobody is suggesting int//int
On Fri, Aug 28, 2009 at 10:46 AM, Neal Becker wrote:
> Charles R Harris wrote:
>
>> On Fri, Aug 28, 2009 at 8:08 AM, wrote:
>>
>>> On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanen wrote:
>>> > Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
>>> >
>>> >> Robert Kern wrote:
>>> >>
>>> >>> On
On Aug 25, 2009, at 2:21 PM, Charles R Harris wrote:
On Tue, Aug 25, 2009 at 1:05 PM, Pierre GM
wrote:
On Aug 25, 2009, at 1:59 PM, Skipper Seabold wrote:
> On Tue, Aug 25, 2009 at 1:51 PM, Charles R
> Harris wrote:
>> Hi Travis,
>>
>> The new parse_datetime.c file contains a lot of c++
What is it?
---
PyOpenCL makes the industry-standard OpenCL compute abstraction available from
Python.
PyOpenCL has been tested to work with AMD's and Nvidia's OpenCL
implementations and allows complete access to all features of the standard,
from a nice, Pythonic interface.
Where can
> ...numpy clean-up...
> ...cruft...
> ...API breakage...
> ...etc
At the risk of starting a flame war, the cleanest way out of the
legacy API trap is some level of fork, with the old code maintained
for some years while new uses (new users and new code by old users)
get done in the new packag
On Fri, Aug 28, 2009 at 9:06 AM, Travis Oliphant wrote:
>
> On Aug 25, 2009, at 2:21 PM, Charles R Harris wrote:
>
>
>
> On Tue, Aug 25, 2009 at 1:05 PM, Pierre GM wrote:
>
>>
>> On Aug 25, 2009, at 1:59 PM, Skipper Seabold wrote:
>>
>> > On Tue, Aug 25, 2009 at 1:51 PM, Charles R
>> > Harris wro
> The main issue is probably just choosing an appropriate float return
> type, and personally I believe this should be same as numpy's default
> float.
I completely agree.
Maybe we could let the user decide whether to use a different type.
It is already somehow possible through the "out" argumen
Joe Harrington wrote:
> However, there are two natural forklets coming up.
>
> The first is Python 3.0, which will necessitate some API changes.
Absolutely! This seems like a no-brainer. I don't think we are talking
about really major changes to the numpy API anyway, generally clean-up,
and the
Folks,
I want to index a[j,k], clipping j or k to the edge if they're 1 off --
def aget( a, j, k ):
""" -> a[j,k] or a[edge] """
# try:
#return a[j,k] -- nope, -1
# except IndexError:
m,n = a.shape
return a[ min(max(j, 0), m-1), min(max(k, 0), n-1)]
On Fri, Aug 28, 2009 at 09:15, Christopher Barker wrote:
> Joe Harrington wrote:
>> However, there are two natural forklets coming up.
>>
>> The first is Python 3.0, which will necessitate some API changes.
>
> Absolutely! This seems like a no-brainer. I don't think we are talking
> about really ma
On Fri, Aug 28, 2009 at 09:14, denis bzowy wrote:
> Folks,
>
> I want to index a[j,k], clipping j or k to the edge if they're 1 off --
>
> def aget( a, j, k ):
> """ -> a[j,k] or a[edge] """
> # try:
> # return a[j,k] -- nope, -1
> # except IndexError:
> m,n = a.sha
On Fri, Aug 28, 2009 at 9:47 AM, Citi, Luca wrote:
> > The main issue is probably just choosing an appropriate float return
> > type, and personally I believe this should be same as numpy's default
> > float.
> I completely agree.
>
> Maybe we could let the user decide whether to use a different
On Aug 28, 2009, at 11:31 AM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 9:47 AM, Citi, Luca wrote:
> The main issue is probably just choosing an appropriate float return
> type, and personally I believe this should be same as numpy's
default
> float.
I completely agree.
Maybe we co
On Fri, Aug 28, 2009 at 10:36 AM, Travis Oliphant wrote:
>
> On Aug 28, 2009, at 11:31 AM, Charles R Harris wrote:
>
>
>
> On Fri, Aug 28, 2009 at 9:47 AM, Citi, Luca wrote:
>
>> > The main issue is probably just choosing an appropriate float return
>> > type, and personally I believe this should
On Fri, Aug 28, 2009 at 8:08 AM, wrote:
> On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanen wrote:
> > Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
> >
> >> Robert Kern wrote:
> >>
> >>> On Thu, Aug 27, 2009 at 14:22, Christopher
> >>> Barker wrote:
> >>>
> By the way -- is there so
Hello folks,
In keeping with the complaint that the pace of NumPy development is
too fast, I've finished the merge of the datetime branch to the core.
The trunk builds and all the (previous) tests pass for me.
There are several tasks remaining to be done (the current status is
definitel
On Fri, Aug 28, 2009 at 12:47 PM, Travis Oliphant wrote:
>
> Hello folks,
> In keeping with the complaint that the pace of NumPy development is too fast, I've finished the merge of the datetime branch to the core. The trunk builds and all the (previous) tests pass for me.
> There are several tasks
On Fri, Aug 28, 2009 at 12:46 PM, Charles R
Harris wrote:
>
>
> On Fri, Aug 28, 2009 at 8:08 AM, wrote:
>>
>> On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanen wrote:
>> > Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
>> >
>> >> Robert Kern wrote:
>> >>
>> >>> On Thu, Aug 27, 2009 at 14:22
On Fri, Aug 28, 2009 at 10:53 AM, Darren Dale wrote:
> On Fri, Aug 28, 2009 at 12:47 PM, Travis Oliphant
> wrote:
> >
> > Hello folks,
> >
> In keeping with the complaint that the pace of NumPy development is too fast,
> I've finished the merge of the datetime branch to the core. The trunk buil
Christopher Barker wrote:
>> Following the full
>> PEP procedure
>or a parallel NPEP system.
Actually, I originally intended just to mean "follow the procedure"
not "do it in their system". But, in thinking about it, if it's
compatible with their system to develop a whole subpackage in their
Hi all,
I ve got a 2d array and i want to iterate over its columns in a "pythonic
way".
This is what i have in mind: please consider this snippet:
#
import numpy as np
array = np.random.standard_normal( (10,10) )
for column in array.some_column_met
On Fri, Aug 28, 2009 at 10:13, davide lasagna wrote:
> Hi all,
> I ve got a 2d array and i want to iterate over its columns in a "pythonic
> way".
> This is what i have in mind: please consider this snippet:
>
> #
> import numpy as np
>
> array = np.r
On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant wrote:
>
> Hello folks,
>
> In keeping with the complaint that the pace of NumPy development is too fast,
> I've finished the merge of the datetime branch to the core. The trunk builds
> and all the (previous) tests pass for me.
>
> There are se
Fons Adriaensen wrote:
> Some weeks ago there was a post on this list requesting feedback
> on possible future directions for numpy. As I was quite busy at that
> time I'll reply to it now.
>
> My POV is that of a novice user, who at the same time wants quite
> badly to use the numpy framework for
--- On Fri, 8/28/09, Christopher Barker wrote:
> long live numpy3k!
>
> -Chris
Or at least until Py4K makes us "fork" again. ;)
DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discu
On Fri, Aug 28, 2009 at 10:39, Charles R
Harris wrote:
> What does UFUNC_OBJ_NEEDS_API do?
It specifies that the ufunc loops need access to the Python C API, so
the dispatcher should not release the GIL before running the loop.
> Hmm, "can also have an additional key called "metadata" which can
On Aug 28, 2009, at 12:39 PM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant > wrote:
Hello folks,
In keeping with the complaint that the pace of NumPy development is
too fast, I've finished the merge of the datetime branch to the
core. The trunk builds and
On Fri, Aug 28, 2009 at 2:43 PM, Travis Oliphant wrote:
>
> On Aug 28, 2009, at 12:39 PM, Charles R Harris wrote:
>
>
>
> On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant
> wrote:
>
>>
>> Hello folks,
>>
>> In keeping with the complaint that the pace of NumPy development is too
>> fast, I've fi
On Aug 28, 2009, at 4:03 PM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 2:43 PM, Travis Oliphant > wrote:
On Aug 28, 2009, at 12:39 PM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant > wrote:
Hello folks,
In keeping with the complaint that the pace of
On Fri, Aug 28, 2009 at 11:18 AM, Robert Kern wrote:
> On Fri, Aug 28, 2009 at 09:15, Christopher Barker
> wrote:
>> Joe Harrington wrote:
>>> However, there are two natural forklets coming up.
>>>
>>> The first is Python 3.0, which will necessitate some API changes.
>>
>> Absolutely! This seems l
39 matches
Mail list logo
