Re: [Numpy-discussion] Why does np.repeat build a full array?

[Sebastian Berg]

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=input_array.shape, strides=(0,))
> 
> 
> I can then use arr e.g. to count certain pairs of elements using
> sparse.coo_matrix. It occurred to me that numpy might have a similar
> function, and found np.repeat. But it seems that repeat actually
> creates the full, replicated array, rather than using stride tricks to
> keep it small. Is there any reason for this?
> 

Two reasons:
 1. For most arrays, arrays even the simple repeats cannot be done with
stride tricks. (yours has a dimension size of 1)
 2. Stride tricks can be nice, but they can also be
unexpected/inconsistent when you start writing to the result array, so
you should not do it (and the array should preferably be read-only IMO,
as_strided itself does not do that).

But yes, there might be room for a function or so to make some stride
tricks more convenient.

- Sebastian

> 
> Thanks!
> 
> 
> Juan.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

[Stephan Sahm]

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 specifying dtype to np.array(). The point is to reduce
the number of entry points for creating numpy arrays."

would this be ok?

On Mon, Dec 14, 2015 at 6:50 PM Robert Kern  wrote:

> 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
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Why does np.repeat build a full array?

[Juan Nunez-Iglesias]

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 elements using
sparse.coo_matrix. It occurred to me that numpy might have a similar
function, and found np.repeat. But it seems that repeat actually creates
the full, replicated array, rather than using stride tricks to keep it
small. Is there any reason for this?

Thanks!

Juan.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Build broken

[Jaime Fernández del Río]

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:

https://travis-ci.org/numpy/numpy/builds/96836128

Thanks,

Jaime

-- 
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Question about nump.ma.polyfit

[Samuel Dupree]

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 executing either numpy.polyfit or numpy.ma.polyfit I get the 
following traceback:


/Users/user/anaconda/lib/python2.7/site-packages/numpy/lib/polynomial.py:594: 
RankWarning: Polyfit may be poorly conditioned

  warnings.warn(msg, RankWarning)
Traceback (most recent call last):
  File "ComputeEnergy.py", line 132, in 
coeffs, covar = np.ma.polyfit( xfit, yfit, fit_degree, 
rcond=rcondv, cov=True )
  File 
"/Users/user/anaconda/lib/python2.7/site-packages/numpy/ma/extras.py", 
line 1951, in polyfit

return np.polyfit(x, y, deg, rcond, full, w, cov)
  File 
"/Users/user/anaconda/lib/python2.7/site-packages/numpy/lib/polynomial.py", 
line 607, in polyfit

return c, Vbase * fac
ValueError: operands could not be broadcast together with shapes (6,6) (0,)


I've attached a stripped down version of the Python program I'm running.

Any suggestions?

Sam Dupree.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
Created on Fri Dec 07 22:25:29 2015

@author: user
"""




from astropy.time import Time
from datetime import datetime
import matplotlib.pyplot as plt
import numpy as np
import os
import string



# set physical constants
# ---
#math constants
#--
rad_per_deg = np.pi / 180.
deg_per_rad = 1. / rad_per_deg

#orbital parameters for Earth
#
GMearth= 3.986004418e14   # in m**3/sec**2
Rearth = 6371.0e3 # in m

count = 0
x = []
y = []

fname = "TLE-ISS-25544.txt"
fhand = open(fname)


print
print "Processing TLEs in ", fname
print "-- "
print


for   line in fhand:
count = count + 1
if line[0] == '1':
sat_number  = line[2:7]
sat_classif = line[7:8]
intl_desig  = line[9:17]
yr= int(line[18:20])
dayno = float(line[20:32])
if yr < 50:
yr = yr + 2000
else:
yr = yr + 1900
elif line[0] == '2':
mean_motion_kozai =  float(line[52:63])
mean_motion   =  mean_motion_kozai * 2.e0 * np.pi / 86400.e0
total_eng = -0.5e0 * ( mean_motion * GMearth ) ** (2.e0/3.e0)
print
print ' sat number   = ', sat_number, ' sat classif = ', sat_classif, ' Internatl Desig = ', intl_desig
print ' yr, dayno= ', yr, dayno
print ' mean motion (Revs/day)   = ', mean_motion_kozai, ' mean motion (rad/sec) = ', mean_motion
print ' Total Energy (m^2/sec^2) = ', total_eng
print

x.append(dayno)
y.append(total_eng)


fhand.close()


count  = len(x)

fit_span   = 9
fit_cycles = count - fit_span + 1
fit_degree = 5

fit_offset = 0

evalpt = fit_span - 1
midpt  = int( np.ceil(fit_span / 2) )

eps= 2.e-16

print
print " Fit Control Parameters "
print " -- "
print " count  = ", count
print " eps= ", eps
print " evalpt = ", evalpt
print " midpt  = ", midpt
print " fit_span   = ", fit_span
print " fir_degree = ", fit_degree
print " fit_offset = ", fit_offset
print " fit_cycles = ", fit_cycles
print

xplot   = []
yplot   = []

yplot_resid = []

dyplot  = []
xdyplot = []


for ifit in range( 0, fit_cycles ):

xfit   = []
yfit   = []
coeffs = []
resids = []
rank   = []
sv = []
rrcond = []
covar  = []

for i in range( 0, fit_span ):
k = i + fit_offset
xfit.append( x[k] )
yfit.append( y[k] )

rcondv  = eps * len(xfit)
#coeffs = np.polyfit( xfit, yfit, fit_degree, rcond=rcondv )
#coeffs, resids, rank, sv, rrcond = np.polyfit( xfit, yfit, fit_degree, rcond=rcondv, full=True )
#coeffs, covar = np.polyfit( xfit, yfit, fit_degree, rcond=rcondv, cov=True )
coeffs, covar = np.ma.polyfit( xfit, yfit, fit_degree, rcond=rcondv, cov=True )

rows = len(covar)

xpoly = xfit[evalpt]
ypoly = np.polyval( coeffs, xfit[evalpt] )

ypoly_resid = ypoly - yfit[evalpt]

xplot.append( xpoly )
yplot.append( ypoly )

yplot_resid.append( ypoly_resid )

p  = np.poly1d( coeffs )
dp = np.polyder( p )
dypoly = dp( xfit[midpt] )

xdyplot.append( xfit[midpt] )
dyplot.append( dypoly )

print
print "ifit = ", ifit
print " fit_offset, fit_offset+fit_size = ", fit_offset, fit_offset+fit_span
print
print " rcondv  = ", rcondv
print
print " coeffs  = ", coeffs
print
print " resids

[Numpy-discussion] Fwd: Python 3.3 i386 Build

[G Young]

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.3 i386 Build
To: numpy-discussion@scipy.org


Hello all,

I was wondering if anyone else has been running into issues with the Python
3.3 i386 build on Travis.  There have been several occasions when the build
has strangely failed (and none of the others did) even though there was no
plausible way for my changes to break it (see here
).  Does anyone have an idea as
to why this is happening?

Thanks!

Greg
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy 1.10.2 release

[Charles R Harris]

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
Sourceforge .
The sources are also available from PyPi
.

Cheers,

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

[Robert Kern]

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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

[Benjamin Root]

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(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.
>
> >>> len(xrange(10))
> 10
> >>> xrange(10)[5]
> 5
>
> --
> Robert Kern
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

[Robert Kern]

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.

>>> len(xrange(10))
10
>>> xrange(10)[5]
5

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] FeatureRequest: support for array construction from iterators

[Benjamin Root]

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 that to fail:

>>> np.array((i for i in range(10)), dtype=np.int_)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: long() argument must be a string or a number, not 'generator'

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 specifying dtype to np.array(). The point is to reduce
the number of entry points for creating numpy arrays.


By the way, any reason why this works?
>>> np.array(xrange(10))
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])


Cheers!
Ben Root


On Sat, Dec 12, 2015 at 6:02 PM, Juan Nunez-Iglesias 
wrote:

> Hey Nathaniel,
>
> Fascinating! Thanks for the primer! I didn't know that it would check
> dtype of values in the whole array. In that case, I would agree that it
> would be bad to infer it magically from just the first value, and this can
> be left to the users.
>
> Thanks!
>
> Juan.
>
> On Sat, Dec 12, 2015 at 7:00 PM, Nathaniel Smith  wrote:
>
>> On Fri, Dec 11, 2015 at 11:32 PM, Juan Nunez-Iglesias
>>  wrote:
>> > Nathaniel,
>> >
>> >> IMO this is better than making np.array(iter) internally call
>> list(iter)
>> >> or equivalent
>> >
>> > Yeah but that's not the only option:
>> >
>> > from itertools import chain
>> > def fromiter_awesome_edition(iterable):
>> > elem = next(iterable)
>> > dtype = whatever_numpy_does_to_infer_dtypes_from_lists(elem)
>> > return np.fromiter(chain([elem], iterable), dtype=dtype)
>> >
>> > I think this would be a huge win for usability. Always getting tripped
>> up by
>> > the dtype requirement. I can submit a PR if people like this pattern.
>>
>> This isn't the semantics of np.array, though -- np.array will look at
>> the whole input and try to find a common dtype, so this can't be the
>> implementation for np.array(iter). E.g. try np.array([1, 1.0])
>>
>> I can see an argument for making the dtype= argument to fromiter
>> optional, with a warning in the docs that it will guess based on the
>> first element and that you should specify it if you don't want that.
>> It seems potentially a bit error prone (in the sense that it might
>> make it easier to end up with code that works great when you test it
>> but then breaks later when something unexpected happens), but maybe
>> the usability outweighs that. I don't use fromiter myself so I don't
>> have a strong opinion.
>>
>> > btw, I think np.array(['f', 'o', 'o']) would be exactly the expected
>> result
>> > for np.array('foo'), but I guess that's just me.
>>
>> In general np.array(thing_that_can_go_inside_an_array) returns a
>> zero-dimensional (scalar) array -- np.array(1), np.array(True), etc.
>> all work like this, so I'd expect np.array("foo") to do the same.
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- http://vorpus.org
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion