(Multi)Tag extent clarification

I thought the extent in Tags is supposed to be the length of the tagged data.
However, the following code gives me length + 1 data because of

nixpy/nixio/multi_tag.py

Line 164 in 2f4ac17

stop += 1

with nix.File.open('test.nix', 'w') as f:
     b = f.create_block('block', 'block')
     arr_y = b.create_data_array('data', 'data', data=np.arange(10000))
     dim = arr_y.append_range_dimension(np.arange(0,10,0.001))
     dim.unit = 's'
     # Tag a stretch of 1 s
     arr_pos = b.create_data_array('pos', 'pos', data=[0])
     arr_ext = b.create_data_array('ext', 'ext', data=[1])
     mt = b.create_multi_tag('tag', 'tag', positions=arr_pos)
     mt.extents = arr_ext
     mt.references.append(arr_y)
 
     # expecting 999 but getting 1000
     print(mt.tagged_data(0, 'data')[-1])

Maybe someone can clarify?

This has been a bit of a pain point for a while. You are correct, the extents return one extra index than one would expect from traditional slicing or indexing semantics. In other words, the range [position, position+extent] is inclusive. I say it's a pain point because most users expect the range to be exclusive [position, position+extent), so that the value at the index position+extent should not be returned from the Tag.

This has been the case since the beginning of NIX, but we recently decided to make it more flexible by allowing users to specify how the indexing/slicing should work and default to the most expected case (exclusive). It's a little bit more complicated than simply removing the last index however, since position+extent can fall in between indexes on the underlying DataArray's dimension. This opens up a set of questions about what should happen if the end point is or is not equal to an index.

We expect the new functionality to be included in the next release. The design document for the new rules is still open for review in a PR on NIX.