-
Notifications
You must be signed in to change notification settings - Fork 1
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
Expression level rewriting #69
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## symbolicutilsinterop #69 +/- ##
========================================================
+ Coverage 74.90% 82.01% +7.10%
========================================================
Files 16 19 +3
Lines 1068 1173 +105
========================================================
+ Hits 800 962 +162
+ Misses 268 211 -57
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The topo sort stuff is looking good. The symbolics integration should target the existing symbolics integration branch.
struct TraversalNode{T} | ||
index::Int | ||
name::T | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My aesthetic sense says these should be in the opposite order because of most significant digit first order. An alternative would be to use MLStyle to create a type that represents the valid elements of an ACSet. When you traverse the ACSet you create an iterable of these types. Then when you consume this list, you use @match
to consume the elements of the iterable. These @data
records could be automatically generated in ACSets.jl from the schema.
module ACSetElements
using MLStyle
abstract type ACSetElement end
@data PodeElement <: ACSetElement begin
Op1(i::Int)
Op2(i::Int)
Var(i::Int)
TVar(i::Int)
Σ(i::Int)
Summand(i::Int)
Name(s::Symbol)
_Type(t) # you can't use Type in ML style because Core.Type
end
end
module ACSetRecords
using MLStyle
abstract type ACSetRecord end
@data PodeRecord <: ACSetRecord begin
Name(s::Symbol)
Operator(s::Symbol)
_Type(t)
Var(name::Name, type::Type)
TVar(incl::Var)
Op1(src::Var, tgt::Var, op1::Operator)
Op2(proj1::Var, proj2::Var, res::Var, op2::Operator)
Σ(sum::Var)
Summand(summation::Σ, summand::Var)
end
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, the unitype design that you did, coupled with an Enum
that captures the available symbols would be good. https://docs.julialang.org/en/v1/base/base/#Base.Enums.@enum and https://thautwarm.github.io/MLStyle.jl/latest/syntax/pattern.html#support-pattern-matching-for-julia-enums could work together to make it easy to write the generic code.
|
||
function is_correct_length(d::SummationDecapode, result) | ||
return length(result) == number_of_ops(d) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also check that when you iterate over the edges in the decapode, we never go from a later vertex to an earlier vertex.
When roundtripping to the SummationDecapode is complete, it would be good to test that the results in |
2a6269c
to
9d8dfca
Compare
I've rebased this branch to work off of PR #64 since the code here will be used for the rewriting using only |
8005495
to
5f78860
Compare
Added `apex` and `@relation`, `to_graphviz` from Catlab Co-authored-by: James <[email protected]>
Converts ACSet to a series of Symbolic terms that can be rewritten with a provided rewriter
Added a short script showcasing how rewriting could be done with the `Sort` types and a reference ACSet.
This now supports the ability for ACSet intermediate expressions to be merged into one single expression upon which rewriting rules (like dd=0) may be performed.
Can take ACSets to Symbolics back to ACSets
This needs to switch to use the new type system
Also switched to using SymbolicsUtils' `substitute`. Still needs tests and code needs to be cleaned up.
378d6a1
to
e0ff9a8
Compare
Addition now works as well but rewriting seems to be janky, unrelated to this pipeline specifically I believe.
…erm meant typed rewriting would fail
This black boxes the intermediate symbolic expressions to the user. The user will simply submit a rewriter that will then be applied
…Equations.jl into gr/acset2sym
…Equations.jl into gr/acset2sym
…Equations.jl into gr/acset2sym
Remove special DerivOp handling, fixed bug where multiple equations with the same variable result were being dropped, more tests to cover these cases and further clean up.
@lukem12345 We wanted to remove this check since it lead to a lot of special code to handle the final ACSet generation. I've removed it in commit 5b84cc8 and added the appropriate tests to ensure it's proper functionality. |
…Equations.jl into gr/acset2sym
…iaLang issue #51325
…failing persistent tasks.
Also set default form dim to 2 and allowed it to vary.
This PR is meant to create a back-and-forth between ACSets, which excel at information propagation (typing, overloading, etc.) and Symbolics, which excel at expression rewriting (open_operators, optimizations, etc.).
This should remove the need for our graph rewriting functions and make the workflow to add new rewrites into the system much more faster/cleaner.