dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Dec 06, 2008 at 03:57:22PM +0100, Martin Sandve Alnæs wrote:
> 2008/12/6 Johan Hake <hake@xxxxxxxxx>:
> > On Saturday 06 December 2008 15:37:15 Martin Sandve Alnæs wrote:
> >> 2008/12/6 Johan Hake <hake@xxxxxxxxx>:
> >> > On Saturday 06 December 2008 14:48:34 Anders Logg wrote:
> >> >> On Sat, Dec 06, 2008 at 02:41:55PM +0100, Johan Hake wrote:
> >> >> > On Saturday 06 December 2008 14:23:40 Anders Logg wrote:
> >> >> > > On Sat, Dec 06, 2008 at 12:02:43PM +0100, Johan Hake wrote:
> >> >> > > > On Friday 05 December 2008 18:02:07 Anders Logg wrote:
> >> >> > > > > I'm having problems getting vector-valued constants working.
> >> >> > > > > Take a look at
> >> >> > > > >
> >> >> > > > >     demo/pde/stokes/taylor-hood/python
> >> >> > > > >
> >> >> > > > > It reports
> >> >> > > > >
> >> >> > > > >     assert(isinstance(defaults[i], (dict,
> >> >> > > > > types.NoneType)),"Wrong type in 'defaults'")
> >> >> > > > >    TypeError: 'NoneType' object is unsubscriptable
> >> >> > > > >
> >> >> > > > > It seems like defaults is set to None and then defaults is
> >> >> > > > > indexed.
> >> >> > > > >
> >> >> > > > > Any ideas?
> >> >> > > >
> >> >> > > > Should be fixed now. I have added better argument checking to
> >> >> > > > compile_function. But you have to send in a tuple of strings to
> >> >> > > > compile_function if you want to produce a vector values function.
> >> >> > > > A list is interpreted as len(cppexpr) number of scalar functions.
> >> >> > > >
> >> >> > > > This is a bit fragile, but it is documented in the Function doc
> >> >> > > > string.
> >> >> > >
> >> >> > > ok! I wasn't aware of the difference.
> >> >> > >
> >> >> > > Maybe we should have both compile_function and compile_functions
> >> >> > > instead of differentiating between tuples and lists?
> >> >> > >
> >> >> > > There is already a compile_functions defined in
> >> >> > > compile_functions.py, but that does not seem to be used. Should it
> >> >> > > be removed (and the name reused for batch-processing functions)?
> >> >> >
> >> >> > compile_functions.py is the orginal work of Martin. It is depricated
> >> >> > now.
> >> >> >
> >> >> > The compile_function module should not be exposed to the user, (Martin
> >> >> > might have a different opinion here) so it should be sufficient with
> >> >> > the Function interface.
> >> >> >
> >> >> > The differences between compiling one and several functions are so
> >> >> > small that I do not think it is usefull to split the code into
> >> >> > different modules.
> >> >> >
> >> >> > One could use the name Functions, instead of Function for batch
> >> >> > processing. In this way we make clear for a user what it means. This
> >> >> > also correlates with the TestFunction/TestFunctions.
> >> >> >
> >> >> > Unfortunaltly will not the case of defining several functions in a
> >> >> > cppcode, argument be covered by this, as the number of compiled
> >> >> > functions will depend on how many functions the user defines in the
> >> >> > cppcode. For this case we could add CostumFunctions, or something.
> >> >> >
> >> >> > Or just keep it the way it is with clearer documentation?
> >> >>
> >> >> Wouldn't it be easy to add an additional argument batch=False to
> >> >> compile_function? Then you could check that argument instead of
> >> >> differentiating between lists and tuples.
> >> >
> >> > So,
> >> >
> >> >  f = Function(V,cppexpr = (("sin(x[0])","cos(x[1])"),
> >> >                           (("sin(x[1])","exp(x[1])"))))
> >> >
> >> > would create a tensor valued function and:
> >> >
> >> >  f, g = Function(V,cppexpr = (("sin(x[0])","cos(x[1])"),
> >> >                              (("sin(x[1])","exp(x[1])")),
> >> >                               batch = True)
> >> >
> >> > would create two vector valued functions. Then we need to explain that
> >> > the use of batch = True, change the meaning of the outermost parentesis
> >> > from a matrix expression to a list expression of two vectors. I have bad
> >> > feeling...
> >> >
> >> > We could also be a bit radical and adapt a pylab.plot interface to the
> >> > compile_function module
> >> >
> >> >  f, c = FunctionExpression(V0,("sin(x[0])","cos(x[1])"),V1,"2.5")
> >> >
> >> > where a space followed by an expression will associate the space with
> >> > that expression. We can have an optional number of (V, cppexpr)
> >> > combinations. And the natural extension of:
> >> >
> >> >  f0, f1, f2  = FunctionExpression("sin(x[0])","cos(x[1])","2.5", space =
> >> > V)
> >> >
> >> > where each compiled function is instantiated with the function space
> >> > defined in 'space'. This could be followed up with e.g:
> >> >
> >> >  CostumFunction(V0,code0,V1,code1)
> >> >
> >> > and
> >> >
> >> >  CostumFunction(code0,code1, space = V)
> >> >
> >> > (The names may not be the best...)
> >> >
> >> > Johan
> >>
> >> I like
> >>
> >> f0, f1, f2 = Functions(V0, code0, V1, code1, V2, code2)
> >>
> >> e.g.
> >>
> >> f0, f1, f2 = Functions(V0, "sin(x[0])",
> >>                                  V1, ("cos(x[0])", "sin(x[1])"),
> >>                                  V2, (("a", "b"), ("c", "d")))
> >
> > Maybee the best? The probelm here is to distinct between code and a scalar
> > expression. Maybee a simple
> >
> >  if "class" in arg:
> >    compilecode
> >  else:
> >    compile_expression
> 
> We'll need to use a regexp to get the class name for construction.
> I think there is some code like that in compile_functions?
> 
> > If this is what we want I rather go for just
> >
> >  Function(...)
> >
> > The analogy to pylab.plot would be that it is named plot not plots.
> 
> The big difference is that plot is a verb and function is a noun.
> plot(a,b,c) can be read "plot these three things" while
> f, g, h = Function(a,b,c) has no such natural language interpretation.
> 
> In fact, I'd like to use "functions" instead, with lower case.

"Function"/"Functions" is better. It indicates that what comes out is
something that can be used in a form, plotted or saved to file, just
like other "Functions".

-- 
Anders


> >> (we will remove Functions from UFL, so I guess the naming is ok after all).
> >>
> >> Have you kept the automatic variable construction? The code above would
> >> make a, b, c, d double variables of f2:
> >>   f2.a = 1.23
> >
> > Yup, together with a 'defaults' argument. This could be added in the above
> > syntax as:
> >
> >   f0, f1, f2 = Function(V0, "sin(x[0])",
> >                         V1, ("cos(x[0])", "sin(x[1])"),
> >                         V2, (("a", "b"), ("c", "d")),{"a":1.0,"b":2.0})
> >
> > These are then optional, but directly tied to the previous expression.
> 
> Nice.
>

Attachment: signature.asc
Description: Digital signature