Devil's advocate here: np.array() has become the de-facto "constructor" for
numpy arrays. Right now, passing it a generator results in what, IMHO, is a
useless result:
>>> np.array((i for i in range(10)))
array( at 0x7f28b2beca00>, dtype=object)
Passing pretty much any dtype argument will cause t
On Mon, Dec 14, 2015 at 3:56 PM, Benjamin Root wrote:
> By the way, any reason why this works?
> >>> np.array(xrange(10))
> array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
It's not a generator. It's a true sequence that just happens to have a
special implementation rather than being a generic container.
Heh, never noticed that. Was it implemented more like a generator/iterator
in older versions of Python?
Thanks,
Ben Root
On Mon, Dec 14, 2015 at 12:38 PM, Robert Kern wrote:
> On Mon, Dec 14, 2015 at 3:56 PM, Benjamin Root
> wrote:
>
> > By the way, any reason why this works?
> > >>> np.array(
On Mon, Dec 14, 2015 at 5:41 PM, Benjamin Root wrote:
>
> Heh, never noticed that. Was it implemented more like a
generator/iterator in older versions of Python?
No, it predates generators and iterators so it has always had to be
implemented like that.
--
Robert Kern
Hi All,
I'm pleased to announce the release of Numpy 1.10.2. This release should
take care of the bugs discovered in the 1.10.1 release, some of them
severe. Upgrading is strongly advised if you are currently using 1.10.1.
Windows binaries and source releases can be found at the usual place on
Sou
I accidentally subscribed to the defunct discussion mailing list, so my
email got rejected the first time I sent to the active mailing list. My
question is in the forwarded email below:
-- Forwarded message --
From: G Young
Date: Mon, Dec 14, 2015 at 3:47 PM
Subject: re: Python 3
I'm running Python 2.7.11 from the Anaconda distribution (version 2.4.1)
on a MacBook Pro running Mac OS X version 10.11.2 (El Capitan)
I'm attempting to use numpy.ma.polyfit to perform a linear least square
fit on some data I have. I'm running NumPy version 1.10.1. I've observed
that in execu
Hi,
Travis is repeatedly being unable to complete one of our test builds. It
all started after I merged a very simple PR that changed a single word in a
docstring, so I have a hard time believing that is the actual cause. Can
anyone who actually knows what Travis is doing take a look at the log:
Hi,
I've recently been using the following pattern to create arrays of a
specific repeating value:
from numpy.lib.stride_tricks import as_strided
value = np.ones((1,), dtype=float)
arr = as_strided(value, shape=input_array.shape, strides=(0,))
I can then use arr e.g. to count certain pairs of el
I would like to further push Benjamin Root's suggestion:
"Therefore, I think it is not out of the realm of reason that passing a
generator object and a dtype could then delegate the work under the hood to
np.fromiter()? I would even go so far as to raise an error if one passes a
generator without
On Di, 2015-12-15 at 17:49 +1100, Juan Nunez-Iglesias wrote:
> Hi,
>
>
> I've recently been using the following pattern to create arrays of a
> specific repeating value:
>
>
> from numpy.lib.stride_tricks import as_strided
>
> value = np.ones((1,), dtype=float)
> arr = as_strided(value, shape=
11 matches
Mail list logo
