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

Introduce Experimental API - Future features #77

Open
mert-kurttutan opened this issue Feb 4, 2023 · 1 comment · May be fixed by #82
Open

Introduce Experimental API - Future features #77

mert-kurttutan opened this issue Feb 4, 2023 · 1 comment · May be fixed by #82
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@mert-kurttutan
Copy link
Owner

Is your feature request related to a problem? Please describe.
Introduce experimental submodule to provide less stable experimental API

Describe the solution you'd like
Put the submodule right below the main module, .i.e. childe module of main module.

Describe alternatives you've considered
None

Screenshots / Text
Not Needed

Additional context
This will be useful for the prototyping some experimental features, see below

@mert-kurttutan
Copy link
Owner Author

mert-kurttutan commented Feb 4, 2023

Features to increase the flexibility of torchview:

  1. Add an option to draw computational graph of methods other than forward
    For instance, we would want to have

    model_graph = draw_graph(model, input_data, model_method="preprocess")

    Issues:

    • record_tensor module is based only on __call__ method. We would need to adapt it based on the method provided.
  2. A context manager to record computation into visual graph: This seems pretty self-explanatory. Create a context manager, e every (torch) operation inside it.

    An example usage:

    with draw_graph(model):
      out = model(in_tensor)
      pred = model.special_infer(in_tensor)

    And you get the computation graph for the entire computation inside the context manager.
    Issues:

    • record_tensor module is based only on call method. We would need to adapt it based on the method provided. This is because a variety of operations will be called inside the context manager. An ideal tool should capture this, otherwise, it is kind of pointless to introduces this feature
    • Register a model with context and manager and its respective methods.

@mert-kurttutan mert-kurttutan self-assigned this Feb 17, 2023
@mert-kurttutan mert-kurttutan added enhancement New feature or request help wanted Extra attention is needed labels Feb 17, 2023
@mert-kurttutan mert-kurttutan linked a pull request Feb 23, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant