Conversation
|
If this fits in with using |
8857c23 to
b9daf72
Compare
|
Sure, I switched the default to |
| """Generate first and last indices of trains to use alongside data | ||
| from ``.ndarray()``. | ||
|
|
||
| If *labelled* is True, returns a pandas dataframe with columns first | ||
| and last. Otherwise, returns a tuple of two NumPy arrays. |
There was a problem hiding this comment.
Nitpicking, could the docstring and the column names refer to 'start' and 'stop' instead of first & last? Or we can find other names.
If you're talking about a section of the data which you'd slice as [10:20], the index of the last item is 19, not 20.
There was a problem hiding this comment.
That's no problem, I don't have any strong feelings and your argument makes sense.
b9daf72 to
ffdd5dd
Compare
|
Thanks! |
|
Thanks for review! I should refrain from making fixup commits with your quick merge finger 🫣 |
|
Oops, sorry. I sometimes get my wires crossed between XFEL projects where I say LGTM and let people merge their own PRs, and projects where I hit merge myself. I'm happy to LGTM a fixup PR if you want to do one. 😉 |
|
No, that's quite alright. I refered to the fact I left a fixup commit in the history, and now it's in |
When using data with more than one entry per train, I find it sometimes convenient (and also regularly more performant) to use plain old ndarrays and have arrays lying around indicating the first and last index of a given train.
This PR adds a method
KeyData.train_index_bounds()to deliver this based onKeyData.data_counts(). I went with the traditionallabelledapproach, though I don't have hard feelings for that.