-
Notifications
You must be signed in to change notification settings - Fork 14
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
Generate Musical Isomorphisms by Default #269
base: main
Are you sure you want to change the base?
Conversation
@@ -5,6 +5,30 @@ using Krylov | |||
using LinearAlgebra | |||
using SparseArrays | |||
|
|||
# Define mappings for default DEC operations that are not optimizable. |
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.
by optimizable do you mean able to be represented by a sparse matrix? The function below is called default_dec_matrix_generate
, which has matrix in the name.
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.
No, for example, the sharp operator is a matrix, but we do not allocate memory for their outputs.
If I recall correctly, the generic term "optimizable" as used in this code base just means that the assignment uses either .=
syntax or the mul!
method when being emitted.
One of the things that I tried to do is amend this state of affairs, by drawing a distinction between operators with special logic that happen to be matrices
, operators with special logic that do not happen to be matrices
, and operators with no special logic and we do not care if they are matrices or not
end | ||
|
||
return (args...) -> op(args...) | ||
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.
I see that the function above is just a move of this + adding the sharp and flat.
@@ -229,11 +229,12 @@ Base.showerror(io::IO, e::InvalidCodeTargetException) = print(io, "Provided code | |||
This creates the symbol to function linking for the simulation output. Those run through the `default_dec` backend | |||
expect both an in-place and an out-of-place variant in that order. User defined operations only support out-of-place. | |||
""" | |||
function compile_env(d::SummationDecapode, dec_matrices::Vector{Symbol}, con_dec_operators::Set{Symbol}, code_target::AbstractGenerationTarget) | |||
function compile_env(d::SummationDecapode, dec_matrices::Vector{Symbol}, con_dec_operators::Set{Symbol}, nonoptimizable_operators::Set{Symbol}, code_target::AbstractGenerationTarget) |
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.
bikeshedding that name: nonoptimized_operators
? Why can't they be optimized? What kinds of optimizations are forbidden?
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.
I believe this name was chosen based on the "closed world assumption"
::CPUBackend => :default_dec_generate | ||
::CUDABackend => :default_dec_cu_generate | ||
_ => throw(InvalidCodeTargetException(code_target)) | ||
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.
the API of a code target should be a function generator_function(::CodeTarget)::Function
generator_function(::AbstractGenerationTarget) = default_dec_generate
generator_function(::CUDABackend) = default_dec_cu_generate # not sure if this should be the function or the symbol? you will get the right namespace by using function instead of symbol.
then at this location you do
default_generation = $(generator_function(code_target))
PS: this match statement is currently inside a loop, but could be hoisted out of the loop, because it doesn't depend on the loop variable.
|
||
# Compilation of the simulation | ||
equations = compile(gen_d, input_vars, alloc_vectors, optimizable_dec_operators, dimension, stateeltype, code_target, preallocate) | ||
data = post_process_vector_allocs(alloc_vectors, code_target) | ||
|
||
func_defs = compile_env(gen_d, dec_matrices, contracted_dec_operators, code_target) | ||
func_defs = compile_env(gen_d, dec_matrices, contracted_dec_operators, nonoptimizable_operators, code_target) |
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.
it is called matrix_optimizable and then nonoptimizable. we should be consistent with the naming conventions.
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.
Please see my other comment referencing the tri-partitioning of operators.
DiagrammaticEquations PR 67 added support for inferring variables as vector fields and resolving the musical isomorphism functions.
This PR updates our docs pages and internal simulation generation to accommodate this new feature.
A future PR should manage the pre-allocation of vectors of SVectors in an
autodiffcache
-able way.@GeorgeR227 assisted in this feature.