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

DerivOp special case in infer_terminals #77

Open
GeorgeR227 opened this issue Sep 26, 2024 · 0 comments
Open

DerivOp special case in infer_terminals #77

GeorgeR227 opened this issue Sep 26, 2024 · 0 comments

Comments

@GeorgeR227
Copy link
Contributor

Currently something is a terminal variable if and only if it is not the source of any other operation. However, something is a source variable if it is not the result of any operation or if it is the source of a Partial T operation. So in the case of ∂ₜ(u) == u, u would be a source variable but not a terminal variable.

For reference, the output decapode looks like this:

SummationDecapode{Any, Any, Symbol} {Var:1, TVar:1, Op1:1, Op2:0, Σ:0, Summand:0, Type:0, Operator:0, Name:0}
┌─────┬───────┬──────┐
│ Var │  type │ name │
├─────┼───────┼──────┤
│   1 │ infer │    u │
└─────┴───────┴──────┘
┌──────┬──────┐
│ TVar │ incl │
├──────┼──────┤
│    11 │
└──────┴──────┘
┌─────┬─────┬─────┬─────┐
│ Op1 │ src │ tgt │ op1 │
├─────┼─────┼─────┼─────┤
│   111 │  ∂ₜ │
└─────┴─────┴─────┴─────┘

In order to balance out this behavior, we should add an case to the terminals that if it is the result of a Partial T operation then it is automatically a terminal.

GeorgeR227 added a commit that referenced this issue Oct 9, 2024
Added a fix to the acset2symbolics code that helps fix the issue caused there by #77. A full fix to this issue can restore the code to just use infer_terminal_names
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant