Skip to content
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

bug: tensor types are not recognized as types #219

Closed
justinchuby opened this issue Nov 29, 2022 · 3 comments · Fixed by #228
Closed

bug: tensor types are not recognized as types #219

justinchuby opened this issue Nov 29, 2022 · 3 comments · Fixed by #228
Labels
topic: torch_lib Related to the torch/aten function lib in development topic: typing Typing related issues

Comments

@justinchuby
Copy link
Contributor

justinchuby commented Nov 29, 2022

Seen in #223

  1. "INT64" expects no type arguments, but 1 given [MYPY]

    def aten_ones(size: INT64[...]) -> TensorType:
  2. Unexpected "..." [MYPY]

    def aten_row_stack(tensors: TensorType[...]) -> TensorType:
  3. INT64 does not accept a default value Default value support in functions #229

    image

@justinchuby justinchuby added help wanted Extra attention is needed topic: torch_lib Related to the torch/aten function lib in development topic: typing Typing related issues and removed help wanted Extra attention is needed labels Nov 29, 2022
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
@abock
Copy link
Contributor

abock commented Dec 2, 2022

The bug here was that TensorType.__getitem__ was returning instances of a new TensorType to carry the shape information. Instead a new type needs to be returned. Should be fixed with #228.

abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
@abock
Copy link
Contributor

abock commented Dec 2, 2022

@justinchuby (3) should be filed as a separate issue please.

abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
…Type instances

This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully TensorType where the dtype and
shape are modeled into the type itself, but it appears that
won't be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to
a proper generic that behavior will remain the same.

Fixes #219
abock added a commit that referenced this issue Dec 2, 2022
This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully generic TensorType where the dtype
and shape are modeled into the type itself, but it appears that won't
be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to a proper
generic that behavior will remain the same.

Fixes #219
@justinchuby
Copy link
Contributor Author

Sure! Created #229

justinchuby pushed a commit that referenced this issue Dec 7, 2022
This ensures that TensorType is never actually instantiated and instead
new TensorType subclasses are created (and cached) for each shape.

This is a stepping stone to a fully generic TensorType where the dtype
and shape are modeled into the type itself, but it appears that won't
be easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to a proper
generic that behavior will remain the same.

Fixes #219
justinchuby added a commit that referenced this issue Dec 7, 2022
…Type instances (#228)

This ensures that `TensorType` is never actually instantiated and
instead new `TensorType` _subclasses_ are created (and cached) for each
shape.

This is a stepping stone to a fully generic TensorType where the dtype
and shape are modeled into the type itself, but it appears that won't be
easily realized until we can depend on Python 3.11.

Importantly, this adds unit tests to ensure if we can move to a proper
generic that behavior will remain the same.

Fixes #219

Co-authored-by: Justin Chu <justinchu@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: torch_lib Related to the torch/aten function lib in development topic: typing Typing related issues
Projects
None yet
2 participants