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

Generate Musical Isomorphisms by Default #269

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lukem12345
Copy link
Member

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.

@@ -5,6 +5,30 @@ using Krylov
using LinearAlgebra
using SparseArrays

# Define mappings for default DEC operations that are not optimizable.
Copy link
Member

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.

Copy link
Member Author

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
Copy link
Member

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)
Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

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)
Copy link
Member

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.

Copy link
Member Author

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.

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

Successfully merging this pull request may close these issues.

2 participants