Thanks. I'll make the changes. -- Anders
On Wed, Apr 01, 2009 at 11:25:28PM +0200, Martin Sandve Alnæs wrote: > It seems important to you, so I won't argue any further. > You're right that it's non-intrusive, so it won't be a big problem. > > Martin > > > 2009/4/1 Anders Logg <[email protected]>: > > On Wed, Apr 01, 2009 at 08:58:09AM +0200, Martin Sandve Alnæs wrote: > >> 2009/4/1 Anders Logg <[email protected]>: > >> > Here are some more thoughts about the (v, w) notation. > >> > > >> > On paper, we have two different ways to express a form. Assuming here > >> > that v and w are two vector-valued functions, one may either write > >> > out the integrals explicitly: > >> > > >> > (1.a) \int_{\Omega} v \cdot w dx > >> > (1.b) \int_{\Omega} v_i w_i dx > >> > > >> > or use the shorthand L^2 inner-product notation: > >> > > >> > (2) (v, w) > >> > > >> > UFL currently supports both (1.a) and (1.b) but not (2). > >> > I think we should support all three. > >> > > >> > What we have now is a mix: > >> > > >> > (3) \int_{\Omega} (v, w) dx > >> > >> Not really. It's a definition, see below. > >> > >> > This doesn't really make sense and we run into all sorts of trouble. > >> > Just consider something like > >> > > >> > a = v*div(inner(w, grad(u)))*dx # works > >> > a = v*div((w, grad(u)))*dx # ??? > >> > >> 1) This doesn't even make any sense. Inner always returns a scalar. > > > > ok, so replace it by > > > > a = inner(v, grad(inner(w, grad(u))))*dx # works > > a = (v, grad((w, grad(u))))*dx # ??? > > > > The point is operators can't be applied to a tuple until it has been > > multiplied by a measure and turned into a Form. > > > >> 2) A proper error message will trigger so it's not a problem. > >> 3) The definition of inner(.,.) and (.,.) is not the same, *dx is > >> currently part of the _definition_ of the latter syntax. > >> 4) Your tuple syntax (u,v) still runs into all sorts of trouble, e.g., > >> k*(u,v), so you're arguing against that as well. > > > > No, it's different. What we have now is a language for expressing > > *integrands*. Then one expects to be able to operate on the > > integrands. The tuple notation is for L^2 inner products and then it's > > not clear on may operate on the inner products except addition, which > > works, and multiplication, which does not work. > > > >> > So I suggest we remove tuples from the form language, in particular > >> > multiplying a tuple with a measure, but add back the possibility to > >> > create a Form from a tuple. This means that there are two different > >> > notations: (1) and (2) and one can be transformed into the other, just > >> > as on paper. Sometimes one notation is convenient, sometimes the > >> > other. > >> > >> The way I see it, we have > >> f*dx > >> which is similar to and defined to represent > >> \int_{\Omega} f dx > > > > Yes. > > > >> and > >> f*dx(0) > >> which is similar to and defined to represent > >> \int_{\Omega_0} f dx > > > > Yes, > > > >> and > >> (u,v)*dx > >> which is similar to and defined to represent > >> (u, v)_{\Omega} > > > > This can be replaced by (u, v). > > > >> and > >> (u,v)*dx(0) > >> which is similar to and defined to represent > >> (u, v)_{\Omega_0} > > > > This can be replaced by (u, v, dx(0)). > > > >> Neither of these look exactly the same in UFL as anyone would > >> write on paper, because we're working within the constraints of > >> a programming language embedded in Python. There are lots > >> of mathematical operations that we cannot write as simply > >> as on paper, so that's not an argument in itself. > > > > But it *is* possible in this case. The notation is > > > > (u, v) > > > > and the implementation is > > > > (u, v) > > > >> > To make it even more explicit, we can move the extraction of a UFL > >> > Form from the constructor of the Form class to a function named > >> > something like tuple2form and place it under ufl.algorithms. The form > >> > compiler may then check the input argument to see whether or not a > >> > call to tuple2form is necessary. > >> > >> That's what load_forms did the short while this was implemented. > >> It doesn't make it any more explicit for the user. > > > > Not for the user, but it separates the tuple notation from the form > > language. The form language remains nice and clean (no tuples, just > > UFL objects) with an additional utility function to transform a tuple > > into a Form. > > > > From the user's perspective, there are two ways to express a form, > > either by writing out the integrands or by writing out the L^2 inner > > products. The form compiler automatically figures out which notation > > is used (either it is a tuple or not a tuple) and makes a simple call > > to tuple2form when necessary. It is simple (it just involves a single > > function call), non-invasive (it doesn't modify the form language like > > the current mix) and it's already implemented. > > > >> It still isn't enough to place this in the form compiler, for example > >> rhs and similar functions require a Form. > > > > We can either live without lhs and rhs for the tuple notation, or we > > could add a simple call to as_form for a limited number of operators > > (like lhs and rhs) that are used to operate on an entire form, which > > is everything in formoperators.py: > > > > lsh > > rhs > > action > > adjoint > > derivative > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > > > iEYEARECAAYFAknTbY8ACgkQTuwUCDsYZdEYpwCgljQhHg5AcVOZjGTro1+AJYvG > > PmEAn14HoIXVinGLM186YdW53WBDy8dH > > =ntRz > > -----END PGP SIGNATURE----- > > > > > _______________________________________________ > FFC-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/ffc-dev
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
