Skip to content

Composing expressions (of unary functions in particular) #18

Open
@oir

Description

@oir
  • Should I prefer free functions (current) or member functions, or both (or a mixture of both for different subsets)? For instance, Eigen uses a.cwiseProd(b) instead of CwiseProd(a, b), similarly PyTorch.
  • If member functions, is it a member function of Ptr<Node> or Node?

Some examples for all three:

NodePtr<> a, b;
auto c = CwiseProd(a, b);
auto c = a.cwise_prod(b);
auto c = a->cwise_prod(b);
NodePtr<> a;
auto b = Exp(Sum(Log(a), /*axis*/ 1));
auto b = a.log().sum(/*axis*/ 1).exp();
auto b = a->log()->sum(/*axis*/ 1)->exp();

Considering that we want expressions to be extensible by user, we can only use a library supporting fixed subset as possible member functions which is a drawback.

Due to some early discussions, leaning towards the third option (chaining by -> with pointer semantics, no changes to Ptr).

Another consideration here is that since this is going to be part of the core interface (either Ptr or Node), these core types will need to know about some derived node types which can lead to wonky forward declarations.

Activity

moved this to 📋 Backlog in Botanicalson Oct 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design question

    Type

    No type

    Projects

    Status

    📋 Backlog

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @oir

        Issue actions

          Composing expressions (of unary functions in particular) · Issue #18 · ginn-org/ginn