-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More indices generalizations #17816
More indices generalizations #17816
Conversation
|
||
Represents the array `y` as an array having the same indices type as `x`. | ||
""" | ||
of_indices(x, y) = similar(dims->y, oftype(indices(x), indices(y))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're only calling this in 2 places, I worry that people might start calling it and hoping it doesn't change or go away
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's basically a test to see if this is something generally useful. Since it's not exported, isn't that reasonable?
I could delete the docstring if you think it would be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleting docs seems like always a bad choice unless they are factually wrong. It is not in the manual so should be fine imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docs is better than no docs, though I guess being documented in the manual has been our rough guideline for when a non-exported API is designed to be called that way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's way too early to put this in the manual---for now this is purely an internal method, and its absence from the manual indicates that pretty clearly I think.
My point is these have a habit of not staying that way - look at all the trouble |
Not the right comparison. |
More complete coverage of iterators/generators/
collect
, coverage oftranspose
andctranspose
,@test_approx_eq
,findn
, andfindnz
.