ufl team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2007/10/30, kent-and@xxxxxxxxx <kent-and@xxxxxxxxx>:
> > On Fri, Oct 26, 2007 at 12:03:06PM +0200, Martin Sandve Alnæs wrote:
> >
> >> I talked with Pearu a little bit yesterday about SymPy and our
> >> requirements for UFL. We might consider building UFL on top of SymPy.
> >> That would give us a lot of symbolic functionality for free, and it
> >> seems to be rather easy to extend with our own specialized objects.
> >> (In that case, we should use the newer sympycore version, not the
> >> current tip). If something is missing, we have Pearu at hand to extend
> >> SymPy.
> >>
> >> http://code.google.com/p/sympy/
> >> http://code.google.com/p/sympycore/
> >>
> >> But lets start with defining what we want UFL to be.
> >
> > My feeling is that our needs for a symbolic engine is quite
> > small. Even if UFL will be able to handle more than FFC, the FFC form
> > language is just about 700 lines of Python (including comments, see
> > algebra.py).
> >
> > But let's leave it open. It would be good if we could avoid
> > dependencies, but if we find ourselves reimplementing a lot of things
> > from SymPy then why not use it.
> >
> > /Anders
>
> ok, lets start defining it and then consider SymPy later.
>
> Kent

Ok. A backside of using SymPy is that we don't have control over its
development, and we won't be able to freeze its syntax the same way we
can with our own UFL.

I think the most complicated features that are missing from my
prototype code that we need are tensor notation which ffc already has,
and differentiation wrt userdefined variables which ffc doesn't have.

I want to implement automatic computation of the Jacobi form J(v,u; w)
from F(v; w) within the UFL framework, which should be very
interesting for the fenics goal "automation of mathematical
modelling", don't you think?

--
Martin