Skip to content

[Bug] Inconsistent definition of the inputs parameter of operators #93

@soodoshll

Description

@soodoshll

Currently, operators have different constructor signatures according to different numbers of input tensors. For example:

  • UnaryOp(Tensor)
  • BinaryOp(Tensor, Tensor)
  • ReduceOp(List[Tensor])

Which causes a problem in

return cls(*inputs, **attributes).run()

No matter which signature the constructor uses, the input tensors will be flattened and stored in inputs attribute of an Operator (with a type of List[Tensor]). When we need to reuse the saved inputs, it's hard to deal with different signatures separately. Maybe it's better to use a unified signature, like Op(List[Tensor])?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions