|
From: | Marco Vassallo |
Subject: | Re: [fem-fenics] interpolate |
Date: | Mon, 19 May 2014 19:49:37 +0200 |
On 19 May 2014, at 18:31, Marco Vassallo <address@hidden> wrote:
On Mon, May 19, 2014 at 5:39 PM, c. <address@hidden> wrote:
Please consider that Octave also has its OOP interface.
On 19 May 2014, at 13:51, Eugenio Gianniti <address@hidden> wrote:
> Since the python interface is already established I would leave the functionspace in second place, as it is. I can move the function on which to interpolate as you suggest, for the C++ interface uses a class method, hence it is different also with current order.
In the default branch this is the "old style" OOP matlab interface,
according to which class methods are invoked as
method_name (object, ....)
so that is the direct translation of the C++ line
object.method_name ()
into Octave language.
Hi,following this point I think it make even more sense to follow the suggestion I gave before:
> - first argument the function or the _expression_ that has to be interpolated
> - 2nd argument the functionspace or the function where the first argument has to be interpolated
the function that has to be interpolated is in fact our object and the space where we interpolate it is the parameter.What do you think?
Following this:
In the current version of Octave the standard syntax
for this kind of operation is of the form:
object = class_method (object, method_arguments)
I would instead leave interpolate as it is. Basically my point is that in the future, when classdef will make it to the stable version, a call like the one up here could just leave the return object aside and work as its C++ counterpart. Probably the problem here is that I am too zealous in trying to stay close to the original FEniCS interface, if you deem the other approach more convenient I will adapt and code accordingly.
Eugenio
Marco
c.
[Prev in Thread] | Current Thread | [Next in Thread] |