Infer Constants From Computation Graph Analysis

[lukem12345]

Currently, users can tag forms as constants using the ::Constant tag in the @decapode eDSL. This is a valuable for tools such as sensitivity analysis and time stepping algorithms we outsource to DiffEq.jl that perform error analysis.

However, with our current typing scheme, tagging a quantity as Constant precludes it from being tagged as a particular differential form, which interferes with type inference. Workarounds have taken place in Decapodes by setting Constants to the infer type and running the type inference algorithm after accessor code from the p named tuple is emitted. Workarounds have also appeared as type inference rules which consider Constants directly where possible.

While these workarounds have allowed for some performance gains, we should ultimately infer which variables are Constants by performing program analysis on the Decapode object. This allows for type inference to execute without being locally blocked by inconvenient tags which shadow valuable information on the degree and primality of differential forms.

So, we should provide an algorithm that determines constants by analyzing the Decapode object. Note that some of these constants may in fact be parameters (functions of time). So, we should allow for the p named tuple to be passed either static values or functions of t, or provide a means of specifying this some other way.

This is closely related to the issue of constant propagation mentioned in issue 51.

[lukem12345]

If we truly want to enforce that a variable must be constant inside the Decapode macro, we could support a syntax such as ::(Constant,Form1) and accommodate this extra type information in the :type attribute of a variable.