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 some
--- On Thu, 8/27/09, Johan Grönqvist johan.gronqv...@gmail.com 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
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 some
Robert Kern wrote:
On Thu, Aug 27, 2009 at 14:22, Christopher Barkerchris.bar...@noaa.gov
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
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
Barkerchris.bar...@noaa.gov wrote:
By the way -- is there something about py3k that changes all this? Or
is this just an opportunity to perhaps make some
On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanenp...@iki.fi wrote:
Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
Robert Kern wrote:
On Thu, Aug 27, 2009 at 14:22, Christopher
Barkerchris.bar...@noaa.gov wrote:
By the way -- is there something about py3k that changes all this? Or
On Fri, Aug 28, 2009 at 8:08 AM, josef.p...@gmail.com wrote:
On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanenp...@iki.fi wrote:
Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
Robert Kern wrote:
On Thu, Aug 27, 2009 at 14:22, Christopher
Barkerchris.bar...@noaa.gov wrote:
Charles R Harris wrote:
On Fri, Aug 28, 2009 at 8:08 AM, josef.p...@gmail.com wrote:
On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanenp...@iki.fi wrote:
Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
Robert Kern wrote:
On Thu, Aug 27, 2009 at 14:22, Christopher
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 Beckerndbeck...@gmail.com wrote:
Charles R Harris wrote:
On Fri, Aug 28, 2009 at 8:08 AM, josef.p...@gmail.com wrote:
On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanenp...@iki.fi wrote:
Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
Robert
On Aug 25, 2009, at 2:21 PM, Charles R Harris wrote:
On Tue, Aug 25, 2009 at 1:05 PM, Pierre GM pgmdevl...@gmail.com
wrote:
On Aug 25, 2009, at 1:59 PM, Skipper Seabold wrote:
On Tue, Aug 25, 2009 at 1:51 PM, Charles R
Harrischarlesr.har...@gmail.com wrote:
Hi Travis,
The new
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
...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 package,
On Fri, Aug 28, 2009 at 9:06 AM, Travis Oliphant oliph...@enthought.comwrote:
On Aug 25, 2009, at 2:21 PM, Charles R Harris wrote:
On Tue, Aug 25, 2009 at 1:05 PM, Pierre GM pgmdevl...@gmail.com wrote:
On Aug 25, 2009, at 1:59 PM, Skipper Seabold wrote:
On Tue, Aug 25, 2009 at 1:51
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 Barkerchris.bar...@noaa.gov 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
On Fri, Aug 28, 2009 at 09:14, denis bzowydenis-bz...@t-online.de 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
On Fri, Aug 28, 2009 at 9:47 AM, Citi, Luca lc...@essex.ac.uk 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
On Aug 28, 2009, at 11:31 AM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 9:47 AM, Citi, Luca lc...@essex.ac.uk 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
On Fri, Aug 28, 2009 at 10:36 AM, Travis Oliphant oliph...@enthought.comwrote:
On Aug 28, 2009, at 11:31 AM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 9:47 AM, Citi, Luca lc...@essex.ac.uk wrote:
The main issue is probably just choosing an appropriate float return
type, and
On Fri, Aug 28, 2009 at 8:08 AM, josef.p...@gmail.com wrote:
On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanenp...@iki.fi wrote:
Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
Robert Kern wrote:
On Thu, Aug 27, 2009 at 14:22, Christopher
Barkerchris.bar...@noaa.gov 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 remaining to be done (the current status is
On Fri, Aug 28, 2009 at 12:47 PM, Travis Oliphantoliph...@enthought.com 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.
On Fri, Aug 28, 2009 at 12:46 PM, Charles R
Harrischarlesr.har...@gmail.com wrote:
On Fri, Aug 28, 2009 at 8:08 AM, josef.p...@gmail.com wrote:
On Fri, Aug 28, 2009 at 9:55 AM, Pauli Virtanenp...@iki.fi wrote:
Fri, 28 Aug 2009 09:46:39 -0400, Neal Becker kirjoitti:
Robert Kern wrote:
On Fri, Aug 28, 2009 at 10:53 AM, Darren Dale dsdal...@gmail.com wrote:
On Fri, Aug 28, 2009 at 12:47 PM, Travis Oliphantoliph...@enthought.com
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
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
On Fri, Aug 28, 2009 at 10:13, davide lasagnalasagnadav...@gmail.com 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
On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant oliph...@enthought.comwrote:
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.
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 his
--- On Fri, 8/28/09, Christopher Barker chris.bar...@noaa.gov wrote:
long live numpy3k!
-Chris
Or at least until Py4K makes us fork again. ;)
DG
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Fri, Aug 28, 2009 at 10:39, Charles R
Harrischarlesr.har...@gmail.com 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
On Aug 28, 2009, at 12:39 PM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant oliph...@enthought.com
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
On Fri, Aug 28, 2009 at 2:43 PM, Travis Oliphant oliph...@enthought.comwrote:
On Aug 28, 2009, at 12:39 PM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant
oliph...@enthought.comwrote:
Hello folks,
In keeping with the complaint that the pace of NumPy
On Aug 28, 2009, at 4:03 PM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 2:43 PM, Travis Oliphant oliph...@enthought.com
wrote:
On Aug 28, 2009, at 12:39 PM, Charles R Harris wrote:
On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant oliph...@enthought.com
wrote:
Hello folks,
On Fri, Aug 28, 2009 at 11:18 AM, Robert Kernrobert.k...@gmail.com wrote:
On Fri, Aug 28, 2009 at 09:15, Christopher Barkerchris.bar...@noaa.gov
wrote:
Joe Harrington wrote:
However, there are two natural forklets coming up.
The first is Python 3.0, which will necessitate some API changes.
36 matches
Mail list logo
