dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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.
 
> > 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.

Johan

> --
> Anders
> 
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~dolfin
> > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~dolfin
> > > More help   : https://help.launchpad.net/ListHelp