Re: [Numpy-discussion] advanced indexing question

[Sebastian Berg]

On Mi, 2015-02-04 at 07:22 +, David Kershaw wrote:
> The numpy reference manual, array objects/indexing/advance indexing, 
> says: 
> Advanced indexing always returns a copy of the data (contrast with 
> basic slicing that returns a view).
> 
> If I run the following code:
>  import numpy as np
>  d=range[2]
>  x=np.arange(36).reshape(3,2,3,2)
>  y=x[:,d,:,d]
>  y+=1
>  print x
>  x[:,d,:,d]+=1
>  print x
> then the first print x shows that x is unchanged as it should be since y 
> was a copy, not a view, but the second print x shows that all the elements 
> of x with 1st index = 3rd index are now 1 bigger. Why did the left side of
>  x[:,d,:,d]+=1
> act like a view and not a copy?
> 

Python has a mechanism both for getting an item and for setting an item.
The latter will end up doing this (python already does this for us):
x[:,d,:,d] = x[:,d,:,d] + 1
so there is an item assignment going on (__setitem__ not __getitem__)

- Sebastian


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

Re: [Numpy-discussion] advanced indexing question

[David Kershaw]

Sebastian Berg  sipsolutions.net> writes:
> 
> Python has a mechanism both for getting an item and for setting an item.
> The latter will end up doing this (python already does this for us):
> x[:,d,:,d] = x[:,d,:,d] + 1
> so there is an item assignment going on (__setitem__ not __getitem__)
> 
> - Sebastian
> 
> 
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion  scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
> 

Thanks for the prompt help Sebastian,

So can I use any legitimate ndarray indexing selection object, obj, in
 x.__setitem__(obj,y)
and as long as y's shape can be broadcast to x[obj]'s shape it will always 
set the appropriate elements of x to the corresponding elements of y?



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

Re: [Numpy-discussion] Any interest in a 'heaviside' ufunc?

[Sturla Molden]

On 04/02/15 06:18, Warren Weckesser wrote:

> By "discrete form", do you mean discrete time (i.e. a function defined
> on the integers)?  Then I agree, the discrete time unit step function is
> defined as

It is the cumulative integral of the delta function, and thus it can 
never obtain the value 0.5. The delta function is defined to have an 
integral of 0 or 1.

Sturla



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

Re: [Numpy-discussion] Any interest in a 'heaviside' ufunc?

[Daπid]

On 4 February 2015 at 11:05, Sturla Molden  wrote:
> On 04/02/15 06:18, Warren Weckesser wrote:
>
>> By "discrete form", do you mean discrete time (i.e. a function defined
>> on the integers)?  Then I agree, the discrete time unit step function is
>> defined as
>
> It is the cumulative integral of the delta function, and thus it can
> never obtain the value 0.5. The delta function is defined to have an
> integral of 0 or 1.
>
> Sturla

There are several definitions. Abramowitz and Stegun
(http://people.math.sfu.ca/~cbm/aands/page_1020.htm) assign the value
0.5 at x=0. It can also be defined as:

H(x) = 1/2 * (1 + sign(x))

Where sign(0) = 0, and therefore H(0) = 1/2.


Actually, Heaviside function is better seen as a distribution instead
of a function, and then there is no problem with the value at 0, as
long as it is finite.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Views of a different dtype

[Jaime Fernández del Río]

On Tue, Feb 3, 2015 at 1:52 PM, Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:

> On Tue Feb 03 2015 at 1:47:34 PM Jaime Fernández del Río <
> jaime.f...@gmail.com> wrote:
>
>> On Tue, Feb 3, 2015 at 8:59 AM, Sebastian Berg <
>> sebast...@sipsolutions.net> wrote:
>>
>>> On Di, 2015-02-03 at 07:18 -0800, Jaime Fernández del Río wrote:
>>> >
>>> 
>>> >
>>> >
>>> >
>>> > Do you have a concrete example of what a non (1, 1) array that fails
>>> > with relaxed strides would look like?
>>> >
>>> >
>>> > If we used, as right now, the array flags as a first choice point, and
>>> > only if none is set try to determine it from the strides/dimensions
>>> > information, I fail to imagine any situation where the end result
>>> > would be worse than now. I don't think that a little bit of
>>> > predictable surprising in an advanced functionality is too bad. We
>>> > could start raising "on the face of ambiguity, we refuse to guess"
>>> > errors, even for the current behavior you show above, but that is more
>>> > likely to trip people by not giving them any simple workaround, that
>>> > it seems to me would be "add a .T if all dimensions are 1" in some
>>> > particular situations. Or are you thinking of something more serious
>>> > than a shape mismatch when you write about "breaking current code"?
>>> >
>>>
>>> Yes, I am talking only about wrongly shaped results for some fortran
>>> order arrays. A (20, 1) fortran order complex array being viewed as
>>> float, will with relaxed strides become a (20, 2) array instead of a
>>> (40, 1) one.
>>>
>>
>> That is a limitation of the current implementation too, and happens
>> already whenever relaxed strides are in place. Which is the default for
>> 1.10, right?
>>
>> Perhaps giving 'view' an 'order' or 'axis' kwarg could make sense after
>> all? It should probably be more of a hint of what to do (fortran vs c) when
>> in doubt. "C" would prioritize last axis, "F" the first, and we could even
>> add a "raise" option to have it fail if the axis cannot be inferred from
>> the strides and shape. Current behavior would is equivalent to what "C"
>> would do.
>>
>> Jaime
>>
>
>
> IMHO, the best option would be something like this:
>
> - When changing to a type with smaller itemsize, add a new axis after the
> others so the resulting array is C contiguous (unless a different axis is
> specified by a keyword argument). The advantage here is that if you index
> the new view using the old indices for an entry, you get an array showing
> its representation in the new type.
> - No shape change for views with the same itemsize
> - When changing to a type with a larger itemsize, collapse along the last
> axis unless a different axis is specified, throwing an error if the axis
> specified does not match the axis specified.
>

My only concern with adding a new axis, backwards compatibility aside, is
that you would not know wether to keep or discard the resulting size 1
dimension when taking a view of the view. We could reuse the keepdims
terminology from ufuncs, though.

So the current behavior would remain unchanged if you set axis=None,
keepdims=True, and we could transition to a more reasonable default with
axis=-1, keepdims=False over a few releases with adequate warnings.

In my mind, when expanding, the axis would not indicate where to place the
new axis, but which axis to collapse over, that is the hard part to figure
out!If you want something else, it is only a call to rollaxis away. Perhaps
we could also give keepdims a meaning when expanding, as to whether to add
a new axis at the end, or change the size of the chosen dimension.

I don't know, there may be an actual interface hidden somewhere here, but
still needs some  cooking to fully figure it out.

Jaime


>
> The last point essentially is just adding an axis argument. I like that
> idea because it gives users the ability to do all that the array's memory
> layout allows in a clear and concise way. Throwing an error if the default
> axis doesn't work would be a good way to prevent strange bugs from
> happening when the default behavior is expected.
>
> The first point would be a break in backwards compatibility, so I'm not
> sure if it's feasible at this point. The advantage would be that all all
> arrays returned when using this functionality would be contiguous along the
> last axis. The shape of the new array would be independent of the memory
> layout of the original one. This would also be a much cleaner way to ensure
> that views of a different type are always reversible while still allowing
> for relaxed strides.
>
> Either way, thanks for looking into this. It's a great feature to have
> available.
>
> -Ian Henriksen
>
>
>>
>>
>>
>>> >
>>> > If there are any real loopholes in expanding this functionality, then
>>> > lets not do it, but we know we have at least one user unsatisfied with
>>> > the current performance, so I really think it is worth trying. Plus,
>>> > I'll admit to that, messing around with some 

Re: [Numpy-discussion] Characteristic of a Matrix.

[Colin J. Williams]

On 06/01/2015 8:38 PM, Alexander Belopolsky wrote:


On Tue, Jan 6, 2015 at 8:20 PM, Nathaniel Smith > wrote:


> Since matrices are now part of some high school curricula, I urge that 
they
> be treated appropriately in Numpy.  Further, I suggest that
consideration be
> given to establishing V and VT sub-classes, to cover vectors and
transposed
> vectors.

The numpy devs don't really have the interest or the skills to create
a great library for pedagogical use in high schools. If you're
interested in an interface like this, then I'd suggest creating a new
package focused specifically on that (which might use numpy
internally). There's really no advantage in glomming this into numpy
proper.


Sorry for taking this further off-topic, but I recently discovered an 
excellent SAGE package, . While it's 
targeted audience includes math graduate students and research 
mathematicians, parts of it are accessible to schoolchildren.  SAGE is 
written in Python and integrates a number of packages including numpy.
My remark about high school was intended to emphasise that matrix 
algebra is an essential part of linear algebra.  Numpy has not fully 
developed this part.  I feel that Guido may not have fully understood 
the availability of the Matrix class when he approved the reliance on dot().


I would highly recommend to anyone interested in using Python for 
education to take a look at SAGE.
Thanks Alexander, I'll do that.  It looks excellent, but it seems that 
the University of Washington has funding problems and does not appear to 
have the crew of volunteers that Python has.


Regards,

Colin W.




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


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

Re: [Numpy-discussion] Characteristic of a Matrix.

[Colin J. Williams]

On 08/01/2015 1:19 PM, Ryan Nelson wrote:

Colin,

I'll second the endorsement of Sage; however, for teaching purposes, I 
would suggest Sage Math Cloud. It is a free, web-based version of 
Sage, and it does not require you or the students to install any 
software (besides a new-ish web browser). It also make 
sharing/collaborative work quite easy as well. I've used this a bit 
for demos, and it's great. The author William Stein is good at 
correcting bugs/issues very quickly.


Sage implements it's own Matrix and Vector classes, and the Vector 
class has a "column" method that returns a column vector (transpose).

http://www.sagemath.org/doc/tutorial/tour_linalg.html

For what it's worth, I agree with others about the benefits of 
avoiding a Matrix class in Numpy. In my experience, it certainly makes 
things cleaner in larger projects when I always use NDArray and just 
call the appropriate linear algebra functions (e.g. np.dot, etc) when 
that is context I need.


Anyway, just my two cents.

Ryan

Ryan,

Thanks.  I agree that Sage Math Cloud seems the better way to go for 
students. However your preference for the dot() world may be because the 
Numpy Matrix Class is inadequately developed.


I'm not suggesting that development, at this time, but proposing that 
the errors I referenced be considered as bugs.


Colin W.


On Wed, Jan 7, 2015 at 2:44 PM, cjw mailto:c...@ncf.ca>> 
wrote:


Thanks Alexander,

I'll look at Sage.

Colin W.


On 06-Jan-15 8:38 PM, Alexander Belopolsky wrote:

On Tue, Jan 6, 2015 at 8:20 PM, Nathaniel Smith  
  wrote:


Since matrices are now part of some high school curricula, I urge that

they

be treated appropriately in Numpy.  Further, I suggest that

consideration be

given to establishing V and VT sub-classes, to cover vectors and

transposed

vectors.

The numpy devs don't really have the interest or the skills to create
a great library for pedagogical use in high schools. If you're
interested in an interface like this, then I'd suggest creating a new
package focused specifically on that (which might use numpy
internally). There's really no advantage in glomming this into numpy
proper.

Sorry for taking this further off-topic, but I recently discovered an
excellent SAGE package,  
.  While it's targeted
audience includes math graduate students and research mathematicians, parts
of it are accessible to schoolchildren.  SAGE is written in Python and
integrates a number of packages including numpy.

I would highly recommend to anyone interested in using Python for education
to take a look at SAGE.



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



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




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


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