Slicing in Python behaves like TDI rather than native/numpy arrays about mdsplus HOT 3 CLOSED

It was not clear what approach is best. I understand your point but in
the case of MDSplus users who have been using only tdi and IDL for
decades and just starting to use python might find the behavior of
python slicing to be strange. If one wants numpy/python behavior then
you can always use the data() method on an MDSplus array to get the
numpy array and slice that. The same is true for "slicing" signals. I
don't think we'd want to change the tdi subscripting behavior of signals
to resemble python slicing. It is a tough decision as to whether to use
tdi slicing of MDSplus objects or python slicing. I intentionally chose
to use tdi slicing for MDSplus objects when I implemented the python
module to retain MDSplus behavior on MDSplus objects. If this is
undesirable we could probably add a global setting to select tdi or
python slicing behavior.

On 4/18/2016 12:26 PM, Brian Standley wrote:

Python (native and numpy) interprets the end index as the first
element not included when slicing arrays, whereas TDI includes the
end element (like IDL). Since indexing in mdsobjects (see
|getitem| in mdsdata.py) eventually calls TdiExecute, MDSplus
arrays behave a bit unexpectedly:
|>>> a = numpy.array([0.4, 0.5, 0.6, 0.7])|
|>>> b = MDSplus.Float32Array(a)|
|>>> a[0:2]|
|array([ 0.4, 0.5])|
|>>> b[0:2]|
|[.4,.5,.6]|

I am happy to make a patch if you think it makes sense to fix it,
probably by adjusting the end index in the aforementioned function.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#452

from mdsplus.

OK, now I understand the reasoning. I do not think a global setting is necessary, but it could not hurt to highlight the implications of MDSplus vs. native types on the wiki. I will see what I can do.

from mdsplus.

I added a note to the wiki:
http://www.mdsplus.org/index.php/Documentation:Tutorial:MdsObjects#Python_Specific_Issues

from mdsplus.