dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Jan 28, 2012 at 01:29:54AM +0100, Johan Hake wrote:
> On Friday January 27 2012 13:34:59 Anders Logg wrote:
> > On Fri, Jan 27, 2012 at 12:48:42AM -0800, Johan Hake wrote:
> > > > Would it help if we do this:
> > > >
> > > > 1. Make GenericFunction::evaluate an inline function that just calls
> > > >   a new version of GenericFunction::eval.
> > > >
> > > > 2. The new version of GenericFunction::eval has the same
> > > >   implementation as the current evaluate() function.
> > > >
> > > > The result would be that we get two eval() functions, one with plain
> > > > pointers and one with Array(). A C++ user (and the JIT-compiled
> > > > expressions) would use the plain pointer version, while the Array
> > > > version gets wrapped for Python subclassing (where I assume the extra
> > > > cost will not make a difference).
> > >
> > > I would discourage this solution as it diverge the interfaces
> > > between C++ and Python
> >
> > I don't see that. In both cases, it would still be
> >
> >   eval(values, x, [cell])
> >
> > in both C++ and Python.
>
> It will clutter the interface.

I don't think it's a big problem.

> > > introduce an interface change which cannot
> > > be backported
> >
> > I don't see that it needs to be backported. The new interface is
> > compatible with the old (same order of the arguments) and old demos
> > would still run (since the Array interface would still be there).
> >
> > > and it circumvents the original problem of Array<>
> > > being costly to instantiate.  Johan
> >
> > Exactly. :-)
>
> Well, then the problem persits. We have a not optimized data
> structure in DOLFIN. It is there for a reason. Having a small
> C-array container with size check is good for other things. Better
> optimize that one, as the concept work just fine.

Whatever works best.

--
Anders