Constant Folding

[lukem12345]

Currently, we perform type inference on Decapodes to infer the degree and primality of differential forms.

However, we could also infer that computations derived solely from constants are also constants. I.e. Constant Folding is a special case of type inference on Variables.

So, we should leverage and augment existing type inference machinery to perform constant folding. The compilation of these down to simulation code is in the realm of Decapodes. The scope of a closing PR for DiagrammaticEquations is to just change uninferred nodes (and optionally Form-typed nodes) to constants when possible.

As with most PRs, this feature would be written differently if we stored whether a form is constant or not separately from the type of differential form it may be.

[lukem12345]

Constants can also be deduced from properties of the algebraic theory, such as two exterior derivatives leading to a Constant 0-valued form. Or, Variable A is 2 times Variable B, Variable C is -1/2 times Variable C, and Variable D is A+B.

Such cases are outside the domain of this issue. They are lower priority, since equations given in the literature usually are presented in fully reduced form. Although maybe someone can find a compelling example. Or maybe such a case can arise from a composition.

[GeorgeR227]

The problems with constant folding here is that constant values are never given to us by the user, only to solve. We merely hold on to their variable names. So if we infer types to be constants, then we'd be asking the user for more given values then they expected to have to give or asking for different ones entirely.

For the case of two exterior derivatives, we can just add a 0-matrix and an identity matrix to the default dec backend.

[lukem12345]

Although that is one way to use this feature, we can still only need the top-level constants. We just add a pre-processing phase that computes downstream constants once beforehand instead of every time inside f. Closures

[GeorgeR227]

I that seems fine but I don't really see any performance gains for doing this. I think most users are going to be using constants for numbers and maybe a few for vectors but those are really light computationally speaking. And in most cases there won't be more than a handful of constants total.

If we can come up with a reasonable example where there is noticeable benefit then we can go ahead and do this.

[lukem12345]

Useful for FEED.

[GeorgeR227]

I'm not familiar with what values are labeled Constant in the FEED model. But I would say in any case to benchmark FEED as is now and with manually applied constant folding to see if we get nice gains.