8000 Please consider adding a NumpySlice type annotation, and exposing Shape, ShapeLike · Issue #16657 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Please consider adding a NumpySlice type annotation, and exposing Shape, ShapeLike #16657

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.

Sign up for GitHub

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

Jump to bottom
Closed
NeilGirdhar opened this issue Jun 21, 2020 · 9 comments
Closed

Please consider adding a NumpySlice type annotation, and exposing Shape, ShapeLike #16657

NeilGirdhar opened this issue Jun 21, 2020 · 9 comments
Labels
41 - Static typing

Comments

@NeilGirdhar
Copy link
Contributor
NeilGirdhar commented Jun 21, 2020 •
edited
Loading

I often use something like this:

NumpySlice = Tuple[Union[int, None, slice, ndarray], ...]

but I guess this is more general?

NumpySlice = Union[ndarray, Tuple[Union[int, None, slice, ndarray], ...]]

Also, why aren't _Shape and _ShapeLike exposed as Shape and ShapeLike? It would be nice to use those and the leading underscore makes them seem private and internal.
@shoyer
Copy link
Member
shoyer commented Jun 22, 2020

Could you elaborate on your use case for NumpySlice? For the most part, I would imagine that makes sense to use more specific types, rather than "everything supported by NumPy's indexing"

Also, why aren't _Shape and _ShapeLike exposed as Shape and ShapeLike? It would be nice to use those and the leading underscore makes them seem private and internal.

These are private and internal :).

  • Shape = Tuple[int, ...] is an example of code so short and simple that it's better to duplicate rather than import it.
  • ShapeLike isn't a type that is used consistently inside NumPy -- there is no single path for canonicalizing or type-checking shapes. Without looking it up, I wouldn't even know what it refers to, e.g., would it include 1D numpy array or not?

@NeilGirdhar
Copy link
Contributor Author
NeilGirdhar commented Jun 22, 2020 •
edited
Loading

Here's where I'm currently using slice:

I use this method:

    def _col_slice(i: SliceLike) -> SliceLike:
        return (slice(None), *i)

here:

        xs = np.linspace(0.0, self.iterations * self.time_step, self.iterations, endpoint=False)
        all_ys = np.asarray(getattr(self.trajectory, name))
        for i in np.ndindex(all_ys.shape[1:]):  # The first index of the trajectory is the time index.  Draw one graph line for each combination of index values over the other indices.
            ys = all_ys[self._col_slice(i)]  # Slice out the data for this graph line.
            axis.plot(xs, ys, label=str(i))

Here's another place:

    def index_into_component(
            self,
            component_index: int,
            slice_into_matched_signals: SliceLike) -> SliceLike:
        """
        Args:
            component_index: The index of the component signals.
            slice_into_matched_signals: A slice into the matched signals.

        Returns:
            The slice corresponding to “slice_into_matched_signals” into signals for component
            “component_index”.
        """
        assert (len(slice_into_matched_signals)
                == len(self._matched_signal_shape))
        retval = []
        for s_i, ic_i in zip(self._non_integer_indices(component_index),
                             slice_into_matched_signals):
            if s_i == np.newaxis:
                continue
            assert s_i == slice(None)
            retval.append(ic_i)
        return tuple(retval)

As for ShapeLike, here's an example that I use to avoid a wasted "add zero" operation in the XLA generated by JAX that I would otherwise get if I used sum:

def sum_tensors(tensors: Collection[Tensor],
                shape: Optional[ShapeLike] = None) -> Tensor:
    if not tensors:
        return jnp.zeros(shape)
    return reduce(add, tensors)

@BvB93
Copy link
Member
BvB93 commented Jun 22, 2020

While I can definitely see its usefulness, I feel that exposing such an annotation to the public namespace would be premature.
Namely we'd first need ndarray the be made generic with respect to its dtype; afterwards we can properly annotate array-like objects consisting of integers or booleans, which is what we'd need for something like the proposed NumpySlice.

@NeilGirdhar
Copy link
Contributor Author

@BvB93 Okay, that makes sense. Are typed ndarray in the plans for 1.20?

@BvB93
Copy link
Member
BvB93 commented Jun 22, 2020

As for as I'm aware there are no concrete plans yet for when proper dtype support will be implemented.
If you're interested then I'd recommend keeping an eye on #16545.

@NeilGirdhar
Copy link
Contributor Author

Thank you, I will do that.

@person142
Copy link
Member

Are typed ndarray in the plans for 1.20?

My goal is yes. Part of the reason for merging the stubs early in the 1.20 release cycle was to get it ironed out.

@person142
Copy link
Member

No promises, but I think I should have updates on this in the weeks time scale.

@NeilGirdhar
Copy link
Contributor Author

That is awesome!!

@NeilGirdhar NeilGirdhar mentioned this issue Feb 16, 2022
Closed
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
41 - Static typing
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@NeilGirdhar @shoyer @person142 @BvB93
0