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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
