octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Patch] fem-fenics patches


From: Daniel Kraft
Subject: Re: [Patch] fem-fenics patches
Date: Wed, 5 Mar 2014 13:07:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

Hi!

On 2014-03-05 12:57, Marco Vassallo wrote:
> On Wed, Mar 5, 2014 at 9:52 AM, c. <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On 5 Mar 2014, at 09:37, Marco Vassallo <address@hidden
>     <mailto:address@hidden>> wrote:
> 
>     > My idea was only that the patch submitted yesterday was an
>     extension of what we already had.
>     > The old syntax still works fine, and I wanted to add the matrix
>     version as soon as possible using Daniel
>     > contribution as a starting point.
> 
>     I still prefer the other approach, joining coordinates of multiple
>     points into a matrix is more consistent
>     with the python API and with the common expectation of Octave/Matlab
>     users that most functions should work
>     as expected when a scalar is substituted by a vector or a vector by
>     a matrix.
> 
> Ok I see your point. I submit a new function as soon as possible.
> Daniel, I hope you don't mind to do something like
> 
> feval (f, [x;y;z])
> 
> instead of
> 
> feval (f, x, y, z)

No, that's fine with my application.

But I have to admit that I still don't understand the point why the
second form should not be used.  In fact, isn't "that most functions
should work as expected when a scalar is substituted by a vector or a
vector by a matrix" precisely an argument *in favour* of the second form?

With the first one, it is not possible to substitute x, y or z with
matrices or column vectors.  The second form is not only consistent with
feval from the rest of Octave (and other functions with multiple
arguments like atan2), but also supports arbitrary shapes of its arguments.

I accept that we want to be consistent with the Python API as far was
possible and thus have the first form available, but in my opinion, the
second form is much more consistent with Octave/Matlab, and thus I think
we should allow it.  After all, fem-fenics is first and foremost an
Octave package, and not just a "port" of the Python API to support also
Octave, IMHO.  I've never used FEniCS in Python before, and it took me
quite some looking into documentations to figure out how feval was
supposed to be called; if it had been possible to use the second form
from above, I would have done it intuitively correctly on the first try.

(But note that I don't have anything to say about Octave development,
this is just my opinion as a user.)

Yours,
Daniel

-- 
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]