Re: [Numpy-discussion] Scipy 2017 NumPy sprint
> From: Marten van Kerkwijk > > Though based on my experience with Quantity, I'd also argue that the > more annoying problems are not so much with `ndarray` itself, but > rather with the helper functions. Just to give an alternative view - as another astronomer I would say that concerns about the use of subclassing in Astropy is one of the reasons I rarely use it. To take an example, if I’m relying on the Quantity class to keep track of my units, then if I have an (N,3) array-like of positions in parsecs, that’s just one step away from going through the sausage-machine of scipy.spatial.cKDTree.query (to find distances to neighbours) and my units are toast. That probably sounds stronger than I meant - keeping track of units systematically is neither easy nor unimportant and I have enormous respect for the developers of Astropy and the community they have built around it. Peter Creasey ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy arrays and slicing comprehension issue
On 8 July 2017 at 13:03, Jaime Fernández del Río wrote: > The last index is exclusive: > [a:b] means a <= index < b. > And the consequence is that the length of your array is b - a, so [:3] gives you the first 3 values. ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy arrays and slicing comprehension issue
The last index is exclusive:
[a:b] means a <= index < b.
On Jul 8, 2017 10:20 AM, wrote:
> Hi
>
> Once again I need your help to understand one topic concerning slicing
> topic, or in other word I do not understand how it works in that particular
> (but common) case; I’m trying to reassign the 4 first values in an array:
>
>- If I use [:3] I’m expecting to have 4 values (index 0 to 3 included)
>- Ditto with [0:3]
>- If I use [3:] I have 2 values as expected (indexes 3 and 4)
>
> Both code and results are presented here after, so this way of thinking
> worked so far in other calculations, and it fails here?
>
>
> Thanks
>
> Paul
>
> ps : extraction from the doc (https://docs.scipy.org/doc/
> numpy/reference/arrays.indexing.html)
>
> *[... all indices are zero-based ...]*
>
>
>
> *Code*:
>
> x = np.random.rand(5); print("x = ",x);
>
> ## test 1
>
> print("partials =\n %s \nor %s \nor %s" %( x[:3], x[0:3], x[3:]) )
>
> print("x[0] : ",x[0]); print("x[1] : ",x[1]); print("x[2] : ",x[2]);
> print("x[3] : ",x[3])
>
>
>
> ## test 2
>
> y = np.ones(4); print("y = ",y)
>
> x[0:4] = y
>
> print("x final = ",x)
>
>
> *Provide*:
>
> x = [ 0.39921271 0.07097531 0.37044695 0.28078163 0.11590451]
>
> partials =
>
> [ 0.39921271 0.07097531 0.37044695]
>
> or [ 0.39921271 0.07097531 0.37044695]
>
> or [ 0.28078163 0.11590451]
>
> x[0] : 0.39921271184
>
> x[1] : 0.0709753133926
>
> x[2] : 0.370446946245
>
> x[3] : 0.280781629
>
> y = [ 1. 1. 1. 1.]
>
> x final = [ 1. 1. 1. 1. 0.11590451]
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Scipy 2017 NumPy sprint
On Fri, Jul 7, 2017 at 6:42 PM, Ryan May wrote: > On Fri, Jul 7, 2017 at 4:27 PM, Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> Hi All, >> >> I doubt I'm really the last one thinking ndarray subclassing is a good >> idea, but as that was stated, I feel I should at least pipe in. It >> seems to me there is both a perceived problem -- with the two >> subclasses that numpy provides -- `matrix` and `MaskedArray` -- both >> being problematic in ways that seem to me to have very little to do >> with subclassing being a bad idea, and a real one following from the >> fact that numpy was written at a time when python's inheritance system >> was not as well developed as it is now. >> >> Though based on my experience with Quantity, I'd also argue that the >> more annoying problems are not so much with `ndarray` itself, but >> rather with the helper functions. Ufuncs were not so bad -- they >> really just needed a better override mechanism, which __array_ufunc__ >> now provides -- but for quite a few of the other functions subclassing >> was clearly an afterthought. Indeed, `MaskedArray` provides a nice >> example of this, with its many special `np.ma.` routines, >> providing huge duplication and thus lots of duplicated bugs (which >> Eric has been patiently fixing...). Indeed, `MaskedArray` is also a >> much better example than ndarrat of a class that is really hard to >> subclass (even though, conceptually, it should be a far easier one). >> >> All that said, duck-type arrays make a lot of sense, and e.g. the >> slicing and shaping methods are easily emulated, especially if one's >> underlying data are stored in `ndarray`. For astropy's version of a >> relevant mixin, see >> http://docs.astropy.org/en/stable/api/astropy.utils.misc.Sha >> pedLikeNDArray.html > > > My biggest problem with subclassing as it exists now is that they don't > survive the first encounter with np.asarray (or np.array). So much code > written to work with numpy uses that as a bandaid (for e.g. handling lists) > that in my experience it's 50/50 whether passing a subclass to a function > will actually behave as expected--even if there's no good reason it > shouldn't. > as a downstream developer: The problem is that we cannot trust any array subclass or anything that pretends to be like an array. Even asarray is letting already too many things go through. We would need an indication or guarantee for the behavior to quack in the correct way, otherwise it is very difficult to write code that would work for various subclasses. (even in the simplest case, writing code that works for matrix and arrays beyond a few lines is getting difficult.) scipy.stats.mstats is largely not code duplication, it needs to handle the mask (although the nan versions in scipy.stats are catching up). Josef > > > Ryan > > -- > Ryan May > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy arrays and slicing comprehension issue
Hi
Once again I need your help to understand one topic concerning slicing
topic, or in other word I do not understand how it works in that
particular (but common) case; I'm trying to reassign the 4 first values
in an array:
* If I use [:3] I'm expecting to have 4 values (index 0 to 3 included)
* Ditto with [0:3]
* If I use [3:] I have 2 values as expected (indexes 3 and 4)
Both code and results are presented here after, so this way of thinking
worked so far in other calculations, and it fails here?
Thanks
Paul
ps : extraction from the doc
(https://docs.scipy.org/doc/numpy/reference/arrays.indexing.html)
_[... all indices are zero-based ...]_
CODE:
x = np.random.rand(5); print("x = ",x);
## test 1
print("partials =\n %s \nor %s \nor %s" %( x[:3], x[0:3], x[3:]) )
print("x[0] : ",x[0]); print("x[1] : ",x[1]); print("x[2] : ",x[2]);
print("x[3] : ",x[3])
## test 2
y = np.ones(4); print("y = ",y)
x[0:4] = y
print("x final = ",x)
PROVIDE:
x = [ 0.39921271 0.07097531 0.37044695 0.28078163 0.11590451]
partials =
[ 0.39921271 0.07097531 0.37044695]
or [ 0.39921271 0.07097531 0.37044695]
or [ 0.28078163 0.11590451]
x[0] : 0.39921271184
x[1] : 0.0709753133926
x[2] : 0.370446946245
x[3] : 0.280781629
y = [ 1. 1. 1. 1.]
x final = [ 1. 1. 1. 1. 0.11590451]___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Scipy 2017 NumPy sprint
Hi Ryan, Indeed, the liberal use of `np.asarray` is one of the main reason the helper routines are relatively annoying. Of course, that is not an argument for using duck-types over subclasses: those wouldn't even survive `asanyarray` (which many numpy routines now have moved to). All the best, Marten ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
