| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Merging this PR will not alter performance⚠️ 1 benchmark measured no execution time
✅ 255 untouched benchmarks Comparing allenflux:oct11-fix-drop-index-order (19e11a2) with master (d9a57b6) |
Sorry, something went wrong.
|
Thanks for the fix! I think it would be better to require the indices to be sorted and let the user check that to avoid performance hit, what do you think? |
Sorry, something went wrong.
Document ordering after negative-index resolution and retain the repeated-normalization offset-map fix with its regression. Generated with OpenAI Codex
|
Thanks again. The failure is unrelated to this PR. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Checklist
Description
Fixes #2595 by documenting the ordering precondition for xt::drop: indices must be in increasing order after negative indices are resolved relative to the sliced axis. For an axis of size 6, drop(0, -1) resolves to {0, 5}, whereas drop(-1, 0) is outside this contract. Callers ensure the order; the library performs no sorting or order check.
Reset the cumulative offset map before rebuilding a reused drop slice. With drop(-2, -1), normalization for axis sizes 4 and then 6 uses ordered positions in both cases, but an old offset entry makes slice(2) return 4 instead of 2. A single two-assertion regression covers this stale state. Existing keep behavior is unchanged.
Validation on macOS arm64 with Apple Clang 21 and C++20:
The existing xsort compilation warnings and non-failing xinfo type-name warning remain unchanged. AI assistance was used for investigation, implementation, tests, validation, and this description. Duplicate and out-of-range indices remain outside this change's scope.