Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Indexing API #166
Indexing API #166
Conversation
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
Signed-off-by: Ryan Nett <[email protected]>
|
More generally these indices don't seem to link up with the indexing operations already available in ndarray, which might prove more confusing as the ndarrays move closer to Tensors given Karl's current refactorings. |
| * <p> | ||
| * - An ellipsis (...) using {@link Index#ellipses()}. Ellipses are used to imply zero or more | ||
| * dimensions of full-dimension selection and are produced using | ||
| * `ellipsis_mask`. For example, `foo[...]` is the identity slice. |
Craigacp
Dec 9, 2020
Collaborator
We don't have this kind of overloading in Java, so does it make sense to describe it here in the Java Ops?
We don't have this kind of overloading in Java, so does it make sense to describe it here in the Java Ops?
rnett
Dec 9, 2020
•
Author
Contributor
I copied most of this from the stridedSlice docs and tried to keep it as close as possible. I talk enough about the Python and Java equivalents that I think it's understood to be stridedSlice(foo, Index.ellipsis()). I'm kind of using it as a generic "slice notation" rather than specifically referencing the Python syntax.
I copied most of this from the stridedSlice docs and tried to keep it as close as possible. I talk enough about the Python and Java equivalents that I think it's understood to be stridedSlice(foo, Index.ellipsis()). I'm kind of using it as a generic "slice notation" rather than specifically referencing the Python syntax.
...e/tensorflow-core-api/src/main/java/org/tensorflow/op/core/Indexing.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Ryan Nett <[email protected]>
|
I looked at that, there's a few concepts that are impossible to map into If we do want to unify APIs, I think it would be easier to map this API onto the current ndarray one the visa versa. To map the ndarray indices onto Operands we'd either have to remove index options, throw runtime exceptions for unsupported ones, or have a |
|
I think extending the ndarray API to cover the gaps would be worthwhile, and then we can throw exceptions for things which fail to map from ndarray into TF ops. |
|
There's some odd things in the ndarray API like |
Fixes #164.
One question: Should I also make endpoints named
getandset? It's more discoverable to people coming from Python (who usually use[]rather than the stridedSlice op).There's examples in the
Indexjavadoc.