dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Saturday 28 November 2009 00:53:51 Anders Logg wrote:
> On Fri, Nov 27, 2009 at 11:59:52PM -0800, Johan Hake wrote:
> > Hello!
> >
> > I have not pushed anything, but Expressions should be up to shape now,
> > and I am working on simplifying the logic in other places of
> > expression.py
> >
> > I do not like the implementation of the dim method. It is used to read a
> > user defined value dimension and then discarded. I suggest that we add a
> > value_shape attribute to the dolfin.Expression class. If not set by the
> > user it is by default (), i.e., a scalar Expression.
> >
> >   class MyExpression(Expression):
> >       value_shape = (2,)
> >       def eval(self, values, x):
> >          values[0] = 1
> >          values[1] = 1
> >
> > The dim name is also only making sense for Vector Expressions, where I
> > think a value_shape attribute makes sense for all occasions. A
> > value_shape for scalar Expression will still be the default.
> 
> I think a dim method makes more sense than adding a variable since it
> is consistent with eval: Then all data a subclassed Expression needs
> to give is defined by a member function.

Ok, but then I think we should keep it and not just pop it from the 
dictionary, so a user can use it after the class is created.

Is it very intuitive that dim stands for value dimension? Should we call it 
value_dim or value_dimension?

> If we need value_shape and value_dimension (which is good to have),
> can't we just store those values as _value_shape, _value_dimension
> after we have figured out the shape and provide member functions that
> return those values?

We already have value_rank and value_dimension in the cpp interface. So it 
might be overkill to have these for no other sake.

> Also note the clever/simplified interface for dim() allowing (1) not
> to overload it for scalars and (2) to return the just the vector
> dimension for vectors: n instead of (n,)).

Yes, I notices.

Johan

> --
> Anders
> 
> > After creation and instantiation we then have an object that have both a
> > shape method (from ufl.Function) and a value_shape attribute from the
> > subclassing definition.
> >
> > What you think.
> >
> > Johan
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>