Closed kynan closed 12 years ago
So do you agree that the index constructors for basis indices should take a count and an element? Or is this still too restrictive for what you want to do? My rationale behind passing it an element as opposed to an argument is that coefficients might need a basis index, and they have an element but not an argument, and arguments also have an element. The element contains enough info to work out the upper bound for the index.
Just seen your comment on issue 50 - I'll continue the discussion in that issue since its more relevant there than here.
So, after fixing Issue 50, the only reason that ExpressionBuilder holds a reference to the FormBackend is to get the number of Gauss points from it. We could completely break the dependence of ExpressionBuilder of having a FormBackend if we passed the number of Gauss points to the constructor of the ExpressionBuilder instead.
Any thoughts @kynan ?
No objections, that seems a very reasonable thing to do.
This issue was fixed in the generate-transforms-experimental branch before it was merged (dfc0aa469f). It turned out that the ExpressionBuilder never needed to know the number of Gauss points (and therefore had no dependency on a FormBackend anymore) because it didn't need to generate linearised array subscripts, which would have contained a multiplication by the number of Gauss points.
ExpressionBuilder
assumes it builds an expression that represents a form (i.e. is the integrand of an integral on a UFLForm
). This restriction is not conceptually necessary and should be lifted. Arbitrary expressions representing a UFLExpr
should be supported.A current limitation are index constructors bound to
FormBackend
, see #50.